CVE-2026-43934
Broken Access Control in e107 CMS
Publication date: 2026-05-26
Last updated on: 2026-05-26
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| e107inc | e107 | to 2.3.4 (inc) |
| e107inc | e107 | to 2.3.4 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-639 | The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. |
| CWE-284 | The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows unauthorized authenticated users to edit comments posted by others, leading to potential data integrity compromise and user trust erosion.
Such unauthorized modifications could impact compliance with standards and regulations that require data integrity and protection of user-generated content, such as GDPR and HIPAA, by enabling unauthorized data alteration and potential misinformation.
This could result in reputational damage and non-compliance risks for platforms handling sensitive or regulated data.
Can you explain this vulnerability to me?
CVE-2026-43934 is a Broken Access Control vulnerability in the e107 content management system (CMS) versions 2.3.3 and earlier.
The vulnerability allows an authenticated but unauthorized user to edit comments posted by other users because the application only uses a predictable identifier in the request to determine which comment to edit, without verifying if the user owns that comment.
Specifically, the `updateComment()` function in the `comment.php` file fails to perform proper access control checks before allowing comment edits.
An attacker can exploit this by sending a crafted POST request with the target comment's identifier, enabling them to modify any comment regardless of ownership.
This issue was fixed in version 2.3.4 by restricting comment edits to the original comment author, ensuring the `comment_author_id` matches the current user's ID before allowing updates.
How can this vulnerability impact me? :
This vulnerability can impact you by allowing unauthorized authenticated users to modify comments posted by others.
Such unauthorized edits can compromise data integrity, leading to misinformation or harassment through altered comments.
It can erode user trust in the platform and potentially damage the reputation of the website or service using the vulnerable e107 CMS.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for unauthorized comment edit attempts by authenticated users who do not own the comments. Specifically, look for POST requests to /comment.php?mode=edit with an itemid parameter referencing comments not owned by the requesting user.
A practical detection method is to analyze web server logs or use network monitoring tools to identify such suspicious POST requests.
Example commands to detect such activity might include:
- Using grep on web server logs to find edit attempts: grep "POST /comment.php?mode=edit" /var/log/apache2/access.log
- Filtering for itemid parameters in requests to identify edits: grep -Po 'itemid=\d+' /var/log/apache2/access.log
- Correlate user sessions or authenticated user IDs with the itemid to check if edits are made on comments they do not own.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability immediately, upgrade the e107 CMS to version 2.3.4 or later, where the issue is fixed by enforcing that only the original comment author can edit their comments.
If upgrading is not immediately possible, administrators can disable comment editing entirely by setting the allowCommentEdit preference to off as a temporary workaround.
Additionally, review any custom forks or plugins that use the comment::updateComment() function to ensure they include proper authorization checks to prevent unauthorized comment edits.