📋 Task Description

Project: Soroban Stellar Core V2.1
Audit Report Source: Link to PDF or Web Report
Portal Status: Uploaded (Please find the report at https://sorobansecurity.com/report/42 to add vulnerabilities)

We are looking for contributors to manually review the audit report linked above and add its individual vulnerabilities to the Soroban Security Portal. This initiative is funded by the Stellar Community Fund via the Drips Protocol network.

This campaign will last for 10 days.
From January 21st - Jan 31st

Please note this requires interacting through the website directly

🛠 Instructions for Contributors

1. Request Access: If you do not have the Contributor role (assigned by us) already or Pilot role in the Stellar Community discord, comment on this issue or ask in our Discord to be manually assigned the role.
2. Locate the Report: Log in to Soroban Security Portal and find the report for Soroban Stellar Core V2.1.
3. PRESS ADD VULNERABILITY

4. Add details Assign the severity of the vulnerability (Critical, High, Medium, Low, etc.) and appropriate tags (Logic Bug, Documentation etc)
5. Continue to Add Vulnerabilities: Create a new vulnerability entry for each finding following the guidelines below.

🛡️ Soroban Security Portal: Contribution & Styling Guidelines

To ensure the Soroban Security Portal remains a high-quality, professional resource for the Stellar developer community, all vulnerability submissions must follow these standardized formatting rules.

The contents of reports are to be treated as a snapshot.

🏗️ Submission Structure

Please note that often times the format depends heavily on the report styling of the auditing company. Veridise reports differ greatly from Ottersec or Halborn for example. Try to match the source material of the report as closely as possible, adding additional details whenever possible.

There are a large amount of reports & vulnerabilities present on the portal already, you can use these as a reference or ask us directly for clarifications on the formatting.

What to do:

• Each vulnerability entry should include the following information when available: Description, Metadata, Recommendation, and Status or Developer Response.
• Description should be present but a section heading is not required as it is included for each vulnerability by default.
• use level 2 headings ( ## ) for sections such as Recommendation, Status, developer response etc.
• for level 2 headings ensure they are bolded
• Ensure the contents of a vulnerability are always be preserved.
• Adding additional context is encouraged such as linking to a specific repository or commit instead of having it presented in plain text.
  • The text "Fixed in 5659d64." is acceptable but " Fixed in 5659d64" is better!
• Ensure all hyperlinks are accessible. If they are not make a note using a * and italics to describe that is inaccessible
• Remove footer images or page numbers
• Ensure proper formatting for code blocks. If it is rust code fore example add "rust" after the code block backticks ``` rust ...
• Ensure all code is are accurate. (it should match as shown in the report)
• If code line numbers are present, be sure to remove them.
• Follow the styling of the report you are adding a vulnerability for

What not to do:

• Do not fix grammatical errors (adding a comma, removing a dash etc.)
• Do not remove or omit any information from the vulnerability
• Do not create markdown tables in the vulnerability
• Do not add any personal opinions or additional comments to the vulnerability.

If you have any additional comments or feedback about a vulnerability you can add it as an individual as a separate comment instead. The comment feature is being worked on to allow this.

1. Audit Metadata

Provide technical context below the description text using Markdown headers. Link directly to the relevant GitHub files if possible.

Some examples of vulnerabilities to model (pending on auditor style)

Function is_registered behaves in a strange way (Veridise)
Unused Return Value (OpenZeppelin)
Missing Validation Logic (Ottersec)
Reward Emissions Accumulate Even When Pool Has No Liquidity, Causing Irrecoverable Token Lock (Cantina)

When possible please add metadata in a format such as the example below. It is usually placed after the description section. However if there is code block present in the description it is best to include it before the code. Use discretion to decide where to place it.

File(s)
path/to/affected/file.rs

Location(s)
function_name()
secondary_function()

2. Vulnerability Details

The description explains the "what" and "why" of the vulnerability.

• Inline Formatting:
  • Use backticks for functions: fund_escrow().
  • Use backticks for roles: platform, approver, service_provider.
  • Use backticks for specific values: 0, None, i128.
• Mathematical Notation: Use LaTeX for complex math ($1~BPS = 0.01%$) but standard text for simple units.
• Always include the Commit ID or PR link if it is available.
• Format: This finding has been addressed in commit ID [6d979b5](https://link-to-commit) in branch develop.
• Title: The title of the vulnerability should match the title in the report. However be sure to remove numerical labels such as [A-03] etc.

For example:

4.1.12 V-GRP-VUL-012: Collection of approved projects can be altered during voting

Should be changed to:

Collection of approved projects can be altered during voting

🛠️ Auditor-Specific Styles

While the metadata remains the same, adapt the Vulnerability flow to match the auditing firm’s native reporting style

⚠️ Critical "PDF-to-Markdown" Checklist

Copying text from PDFs often introduces hidden errors. Check your work for:

1. Ghost Layers (Duplication): PDFs often duplicate words when copied (e.g., SafeMathSafeMath or ::safe_mul_divsafe_mul_div). Manually remove these.
2. Missing Symbols: Characters like {, }, ;, ?, or : can be "lost" or rendered as invisible gray text in some PDF viewers. Ensure the code block is syntactically correct.
3. Broken Quotes: Ensure "smart quotes" from the PDF are converted to standard programming quotes (") so the code remains valid.
4. Internal References: If one vulnerability (e.g., [A04]) is mentioned in another, ensure the reference ID matches the report exactly.

🤝 Need Help?

Reach out to us directly here or via our discord

🤝 Assignment

Please comment on this issue if you would like to volunteer for this report. Our staff will review your submissions.