Security vulnerabilities

451

136
Both requests use identical, empty cookie jars. The closed task returns 3.3x more content — the full report body — while the open task returns only the login-gated shell page. This isolates the defect to task status, ruling out session leakage or caching artifacts as an explanation.

Step 4 — Confirm the pattern is systemic across multiple closed tasks
for id in 401 415 423 426 440 443; do

echo "=== task/$id ==="
curl -sk -o /tmp/task_$id.html -w "HTTP:%{http_code}\n" \
  "https://security.alwaysdata.com/task/$id"
grep -o '<title>[^<]*</title>' /tmp/task_$id.html

done
Result — all six closed tasks return HTTP 200 with full titles rendered, unauthenticated:

HTTP:200
<title> FS#401  : Critical SSRF via Application Script Source URI — Cross-Tenant Data Leak</title>

HTTP:200
<title> FS#415  : SSTI → RCE on Core Infrastructure Server (overlord-core)</title>

HTTP:200
<title> FS#423  : Broken Object Level Authorization (IDOR) → Mass PII Disclosure</title>

HTTP:200
<title> FS#426  : Internal staff account and privilege hierarchy disclosure via SSH</title>

HTTP:200
<title> FS#440  : Incomplete Fix for  FS#426  - Staff Files Still Publicly Accessible via Symlink</title>

HTTP:200
<title> FS#443  : Authenticated API Disclosure of DKIM Private Keys</title>
[Screenshot 4 — attach here: full terminal output of this loop]

Step 5 — Independent surface: RSS feed leaks the same data without authentication
curl -sk "https://security.alwaysdata.com/feed.php?feed_type=rss2&project=1"
Returns task titles, authors, and publish dates for recently filed reports without authentication — including reports as recent as 2–3 days old at test time ( FS#442 ,  FS#443 ). This confirms a second, independent code path exposes the same underlying data, and that newly filed reports enter the exposed state quickly.

Impact What is exposed, concretely, right now, to any unauthenticated internet user:

Complete vulnerability disclosure content for every closed report on the tracker, including:

Exact vulnerable endpoints and affected infrastructure hostnames
Full reproduction steps, in some cases including working exploit/PoC scripts
CVSS scores and severity classifications
Internal staff usernames and reporter identities
Private comment threads between alwaysdata staff and reporters

2)A live reconnaissance dataset spanning multiple vulnerability classes, confirmed present across the six tasks tested alone: SSRF ( FS#401 ), server-side template injection leading to RCE ( FS#415 ), IDOR/mass PII disclosure ( FS#423 ), internal account disclosure ( FS#426 ), symlink-based file exposure ( FS#440 ), and API key disclosure ( FS#443 ). The RSS feed additionally surfaces titles for further reports ( FS#427 ,  FS#429 ,  FS#430 ,  FS#432 ,  FS#433 ,  FS#442 ) not deep-tested here but following the identical exposure pattern.

3)A demonstrated fix-verification gap. The tracker's own history shows this is not a theoretical risk:  FS#426  was closed as fixed, and within 6 days a bypass of that exact fix was filed as  FS#440  — the bypass author could only have known the precise remediation detail (which NSS entries were removed, without the underlying file permissions being fixed) by reading the closed  FS#426  report on this same publicly-accessible tracker.

4)Real-time exposure of new reports. The RSS feed surfaces new task titles within hours of filing, meaning the window between "vulnerability reported" and "details become guessable/discoverable via title" is effectively zero, independent of whether the underlying bug has been fully remediated across all affected infrastructure.

5)Attack surface mapping at scale. Two years of closed reports on this tracker constitute a complete map of every vulnerability class alwaysdata's own infrastructure has been susceptible to, the exact endpoints involved, and in several cases exploit code — usable by an attacker to identify recurring weak points (e.g., the file-permission/symlink issue spanning both  FS#426  and  FS#440 ) without ever probing the live application themselves.

Remediation Immediate:

Enforce the same authorization check on closed tasks that is currently correctly applied to open tasks. Task visibility must be gated by project membership/authentication regardless of status.
Audit the Flyspray permission configuration for the "Security vulnerabilities" project to identify why the anonymous-access check is being bypassed specifically for closed-status tasks — this is most likely a conditional in the task-rendering logic that special-cases closed tasks (e.g., for public changelog purposes) without accounting for the confidentiality requirement of a private security tracker.

RSS feed:

Require authentication for /feed.php or disable it for the Security vulnerabilities project.
If transparency is a goal:

Publish a separate, manually curated advisories page with sanitized summaries only, released on a fixed delay (e.g., 90 days) after full remediation is verified across all affected infrastructure — do not rely on the tracker's native closed-task view for this purpose.

Kind Regards
Team TrinityXploit