Summary
A stored cross-site scripting vulnerability in phpMyFAQ allows unauthenticated or low-privileged users to place JavaScript in submitted FAQ content. The script may execute in an administrator's browser when the entry is reviewed or edited, potentially enabling session theft and administrator account takeover.
Affected context
The vulnerability occurs in phpMyFAQ workflows that accept user-submitted FAQ entries and later display them to administrators. Risk increases when submitted content is decoded after filtering and rendered through a template path that trusts the resulting HTML without context-appropriate output escaping.
Exploit preconditions
- Attack surface: User-submitted FAQ content displayed in an administrative interface
- Required access: No authentication or, where configured, a low-privileged registered account capable of submitting content
- Trigger point: An administrator reviews or edits the affected FAQ entry
- Why exploitation is possible: Entity decoding can reintroduce executable markup after tag filtering, while the administrative template renders the content as trusted raw HTML
Why this happens
The underlying flaw is a mismatch between input filtering, entity decoding, and output encoding. The application applies strip_tags() before html_entity_decode(), allowing encoded markup to become active after filtering has completed. The administrative template then uses Twig's |raw filter without appropriate contextual escaping, mapping to CWE-79: Improper Neutralization of Input During Web Page Generation.
Potential impact
- An attacker may execute JavaScript in an administrator's browser
- An attacker could steal or misuse administrator session information
- Administrative accounts may be taken over
- FAQ content or application settings could be modified
- The vulnerability may enable further actions available to the compromised administrator
General mitigation guidance
Mitigation generally focuses on treating submitted content as untrusted throughout its entire processing lifecycle.
Common defensive patterns include:
- Applying context-aware output encoding at the final rendering boundary
- Avoiding raw template rendering for user-controlled content
- Using a well-defined, restrictive HTML allowlist when rich text is required
- Performing sanitization after decoding transformations and before rendering
- Reducing administrative privileges and limiting session permissions
- Using browser protections such as an effective Content Security Policy as defense in depth
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis rules identifying raw template rendering of request-derived data
- Code review checks covering decode, filter, sanitize, and output-encoding order
- Tests containing encoded markup and script-bearing input in all user-submission fields
- Policy enforcement that requires contextual escaping for administrative views
- Monitoring for unexpected script-capable content in FAQ records and anomalous administrator sessions
- Automated security review tools that trace untrusted data into HTML responses
