Back github.com

GHSA Mpq9 V47x 3hw8

github.com • October 3, 2026

The three API endpoints load an issue by id and check only that the row exists ( if ($issue->id) ), never calling Model\Issue::allowAccess() . When an administrator has enabled security.restrict_access (which limits issue visibility to the owner, author, or group), any authenticated principal with a valid API key can therefore read the full contents and of any issue, including owner and author email addresses, and post to restricted issues. The same codebase enforces allowAccess() in the web UI issue view and in the sibling write endpoints single_put and single_delete , making this an inconsistent, missing authorization check at these specific call sites rather than intended behavior.

app/controller/api/issues.php single_get (GET /issues/@id.json ), approx. line 291 single_comments (GET /issues/@id/ .json ), approx. line 324 single_comments_post (POST /issues/@id/ .json ), approx. line 345

single_get (GET /issues/@id.json ), approx. line 291

single_comments (GET /issues/@id/ .json ), approx. line 324

single_comments_post (POST /issues/@id/ .json ), approx. line 345

app/model/issue.php : allowAccess() , approx. line 605 (authorization routine that is not called by the endpoints above)

Reference enforcement that is present elsewhere: app/controller/issues.php (web UI, lines 217 and 436) and the sibling API methods single_put (line 255) and single_delete (line 313), all of which do call allowAccess() .

Preconditions: security.restrict_access=1 ; a confidential issue #1 owned by user alice ; a low privilege user bob in an unrelated group with his own API key.

Reproduced deterministically; the web UI returns HTTP 404 for the same user while the API returns HTTP 200.

Any authenticated account or API key holder can defeat the security.restrict_access confidentiality control: full read of all restricted issues and their , including owner and author email addresses, plus unauthorized writes to restricted issues. API keys are long lived and per user, and no CSRF or user interaction is required. The read exposure affects every restricted issue in the instance, not only the attacker's own, and written persist on the victim issue.

The full story

This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.

CVE-2026-104991: High-Risk API Vulnerability in Phproject CVE-2026-104991, published on October 2, 2026, identifies a missing object-level authorization vulnerability in Phproject versions prior to 1.8.7. This flaw allows authenticated API key holders to bypass security controls, enabling unauthorized access to restricted issue contents and the ability to post unauthorized comments. Organizations with internet-accessible instances are particularly at risk, especially those with broadly distributed or long-lived API keys. The vulnerability has a CVSS score of 7.1, indicating a high risk, but there is currently no confirmed active exploitation or proof-of-concept code available. Administrators are advised to review API logs and restrict access until a patch is applied. The vendor has not yet confirmed the urgency of this issue, and no exploitation status has been reported. 1 sources 62

GHSA Mpq9 V47x 3hw8

The full story

Extracted Entities

Attack Types (1)

CWE Weaknesses (2)