Skip to main content

Phproject CVE-2026-104991

| EUVDEUVD-2026-91776 HIGH
Missing Authorization (CWE-862)
2026-10-02 VulnCheck GHSA-697f-vmv6-cx6w
7.1
CVSS 4.0 · Vendor: VulnCheck
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Obtain valid Phproject API key
  2. Delivery
    Call /issues/{id}.json for restricted issue
  3. Exploit
    Server skips allowAccess() check
  4. Execution
    Read restricted contents and author emails
  5. Impact
    Post unauthorized comment to restricted issue

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK

1 technique across 1 tactic: Privilege Escalation

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Exploitation requires (1) the Phproject instance to have the 'Restrict issue access' (security.restrict_access) confidentiality control enabled - on instances without this control there are no restricted issues to leak - and (2) the attacker to possess a valid, active API key for any account on that instance. The affected endpoints are the REST API issue routes single_get (GET /issues/{id}.json), single_comments (GET /issues/{id}/comments.json), and single_comments_post (POST /issues/{id}/comments.json), which never call allowAccess(). Limiting factors: this is not remote-unauthenticated - PR:L means a valid API key is mandatory; impact is bounded to reading restricted issue data (including owner/author emails) and posting comments, with no broader write or availability impact; affected versions are 1.1.6 through 1.8.6, fixed in 1.8.7.

Impact

This is a genuine but moderate-priority issue, not an inflated high-CVSS finding. The vendor-assigned CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N, 7.1) is internally consistent with the description: exploitation is network-reachable, low-complexity, and requires low privileges - specifically a valid API key (PR:L), which is a real authentication barrier that meaningfully limits the attacker population to existing account/key holders. The dominant impact is confidentiality (VC:H: disclosure of restricted issue contents and owner/author email addresses), with only low integrity impact (VI:L: posting unauthorized comments) and no availability impact. No EPSS score, CISA KEV listing, or public POC was provided in the input; per precision rules this is 'no public exploit identified at time of analysis.' The absence of KEV/EPSS data combined with PR:L and a niche product suggests low likelihood of widespread opportunistic exploitation. The one SSVC-relevant note: technical impact is partial (data read + limited write), it is not automatable at scale given the per-key, per-instance nature, and exploitation status is non-evidenced. There are no conflicting signals - the CVSS vector matches the description well; the main limitation is simply that exploitation-probability telemetry (EPSS/KEV/POC) is entirely absent, so risk is inferred from the vector and advisory alone.

Exploit ScenarioDerived

An authenticated user of a Phproject instance that has 'Restrict issue access' (security.restrict_access) enabled uses their own valid API key to call GET /issues/{id}.json or /issues/{id}/comments.json for issues they are not authorized to see, reading confidential issue bodies and owner/author email addresses. The same key can POST to /issues/{id}/comments.json to inject comments into restricted issues. No public exploit code is identified, but the attack requires only trivial, well-documented REST calls with a valid key.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 02, 2026

Authenticated API key holders can read restricted issue contents and comments in Phproject (versions 1.1.6 through 1.8.6) because the REST API issue endpoints single_get, single_comments, and single_comments_post never invoke the allowAccess() authorization routine, silently bypassing the security.restrict_access confidentiality control. Attackers with any valid, active API key can retrieve restricted issues and comments - including owner and author email addresses - and post unauthorized comments to issues they should not be able to access. Exploitation requires the target instance to have 'Restrict issue access' enabled and a valid API key; no public exploit code has been identified at time of analysis, and impact is bounded to information disclosure plus limited unauthorized writes with no availability impact. Fixed in Phproject 1.8.7.

RemediationAI

Upgrade to Phproject 1.8.7 or later - the vendor-released patch that fixes this issue - following the guidance in GHSA-mpq9-v47x-3hw8 and the v1.8.7 release notes at https://github.com/Alanaktion/phproject/releases/tag/v1.8.7. After upgrading, verify the corrected behavior: GET /issues/{id}.json and GET /issues/{id}/comments.json should return 403 for issues the key's owner cannot access, POST /issues/{id}/comments.json should return 403 likewise, and GET /issues.json plus GET /tag/{tag}.json should list only accessible issues. Because the bypass depends entirely on possessing a valid API key, immediate compensating controls include revoking or rotating all active API keys, disabling API key issuance for non-administrative users, and treating stale keys as compromised; the trade-off is that this breaks any legitimate integrations relying on those keys until they are reissued after patching. If upgrading cannot be done promptly, block external access to the /issues/ REST routes and /atom.xml at the reverse proxy or WAF, and restrict the API to trusted networks or administrative accounts, accepting that this disables API-driven workflows. Note that the same 1.8.7 release also invalidates API keys belonging to deleted users (REST returns 401, Atom feed returns 403) and restricts author_id spoofing in POST /issues.json to administrators, so a full upgrade is preferable to partial mitigation. Instances that do not enable security.restrict_access are not exposed to this specific confidentiality impact, but should still upgrade to address the companion authorization defects.

Affected VersionsENISA

Phproject 1.1.6 <1.8.7

Affected Packages

euvd phproject fix: 1.8.7

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

CWE-862 (Missing Authorization) affects Phproject, an open-source project management application written in PHP by Alanaktion. The flaw is a missing object-level (per-object) authorization check: the REST API route handlers single_get (GET /issues/{id}.json), single_comments (GET /issues/{id}/comments.json), and single_comments_post (POST /issues/{id}/comments.json) return data and accept writes without calling the application's allowAccess() routine, which is the enforcement point the web interface relies on when security.restrict_access is enabled. Because the check is omitted rather than misconfigured, any holder of a valid API key - including one scoped to a user who should not see the issue - reaches the underlying objects directly. The same v1.8.7 security release also corrected adjacent access-control defects on the same code paths: the Atom feed (GET /atom.xml?key=…) leaked restricted issues via type=all or by supplying another user's username; API keys belonging to deleted users continued to authenticate; POST /issues.json accepted an arbitrary author_id, allowing issue spoofing (now admin-only); and GET /issues.json and GET /tag/{tag}.json now filter results to issues the caller can access, with deleted issues hidden from non-admin users. The CVSS:4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N) is consistent with the independent assessment (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N): network-reachable, low complexity, no user interaction, but requiring low privileges (a valid API key), yielding high confidentiality impact and low integrity impact with no availability impact.

Know when Phproject gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (VulnCheck) PRIMARY 7.1 HIGH
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N
vuln.today AI 7.1 HIGH

Network REST API, low complexity, but a valid API key is required so PR:L not PR:N; high confidentiality from leaked restricted issues/emails, low integrity from comment posting, no availability impact.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
None
Privileges Required
Low
User Interaction
None
Vulnerable system: Confidentiality
High
Vulnerable system: Integrity
Low
Vulnerable system: Availability
None
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

Lifecycle Timeline

2
Patch available
Oct 02, 2026 - 20:03 EUVD
CVE Published
Oct 02, 2026 - 19:33 cve.org
HIGH 7.1

DescriptionCVE.org

Phproject before 1.8.7 contains a missing object-level authorization vulnerability in the REST API issue endpoints (single_get, single_comments, single_comments_post) that allows authenticated API key holders to bypass the security.restrict_access confidentiality control by never invoking the allowAccess() authorization routine. Attackers can use a valid API key to read restricted issue contents and comments, including owner and author email addresses, and post unauthorized comments to issues they should not have access to.

Technical POC Analysis

CWE-862 (Missing Authorization) - specifically missing object-level authorization.

Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.

Executive ViewAI

Why It Matters

Phproject releases 1.1.6 through 1.8.6 allow anyone holding a valid API key to read issues and comments that the platform was configured to restrict, because three REST endpoints never run the access-control check, exposing confidential project content along with owner and author email addresses. Organizations self-hosting an affected version with 'Restrict issue access' enabled are exposed to silent data disclosure by any key holder - including contractors, integration accounts, or leaked credentials - plus unauthorized comments posted under legitimate threads. No public exploit code has been identified at time of analysis, and a vendor fix is already available, so the exposure is bounded but should be closed promptly.

Business Impact: Medium
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.2%
Top 89% exploitable
Prevalence
Low
niche open-source PHP project-management app, limited enterprise footprint
Data Quality
6 sources
Confidence: High

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
Poc
System Exposure· derived
Open
Automatable
No
Human Impact
Medium
Technical Impact
Partial

Priority Score

36
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +36
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy