GHSA-88g4-74f3-63x9 is a medium-severity (CVSS 4.9) Path Traversal vulnerability in thorsten/phpmyfaq. O3 Security confirms whether GHSA-88g4-74f3-63x9 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
phpMyFAQ has Potential Authenticated Path Traversal in PDF Export
Real-World Exposure
thorsten/phpmyfaq🐘phpmyfaq/phpmyfaqReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Summary
There is an authenticated path traversal condition in the PDF export functionality, specifically within the PDF image resolution logic.
The issue may allow a privileged FAQ editor to cause the application to attempt reading files outside the intended content directory during PDF generation.
Affected Component
File:
src/phpMyFAQ/Export/Pdf/Wrapper.php
Function:
concatenatePaths()
Root Cause
The path resolution logic relies on locating the substring "content" within a user-controlled path:
$pos = strpos($trimmedFile, 'content');
$relativePath = substr($trimmedFile, (int) $pos);
If "content" is not present, strpos() returns false, which becomes 0 when cast to an integer.
As a result, the entire attacker-controlled path is preserved.
Example:
$trimmedFile = "../../../etc/passwd";
$pos = false;
$relativePath = "../../../etc/passwd";
The resulting path is later processed by:
file_get_contents($resolvedPath);
without canonicalization or a root-directory containment check.
Observed Data Flow
FAQ Content
->
PDF Export
->
WriteHTML()
->
Wrapper::Image()
->
concatenatePaths()
->
file_get_contents()
Potential Impact
Based on code review, a user with FAQ editing privileges may be able to store HTML containing crafted image paths that are processed during PDF generation.
Potential consequences may include:
- Path traversal outside the intended content directory
- Local file read attempts during PDF export
- Possible disclosure of readable files depending on file type, sanitization behavior, and PDF rendering constraints
Discovery Method
This issue was initially detected by an internally developed SAST tool during analysis of the phpMyFAQ source code.
The finding was then manually investigated and validated through code review.
While the original scanner output classified the issue as a generic path traversal/local file inclusion pattern, manual analysis identified the specific root cause in the path resolution logic of concatenatePaths().
Potential Exploitation Scenario
The following scenario is based on code review and intended to illustrate the potential impact:
-
A user with FAQ editing privileges creates or modifies a FAQ entry.
-
The FAQ content contains an HTML image tag with a crafted relative path that does not include the expected
contentdirectory reference. -
The HTML content is stored and later processed by the PDF export functionality.
-
When a user requests the PDF version of the FAQ, the application invokes
WriteHTML(), which eventually reachesWrapper::Image(). -
concatenatePaths()constructs a filesystem path without canonicalization or directory containment validation. -
The resulting path reaches
file_get_contents(), causing the application to attempt reading a file outside the intended content directory. -
Depending on sanitization behavior, file permissions, image validation, and PDF rendering behavior, the contents of the targeted file may potentially be exposed to the PDF consumer.
Based on my current analysis, exploitation would require a user capable of editing FAQ content and is therefore not considered an anonymous or unauthenticated attack vector.
Suggested Remediation
Consider replacing substring-based path anchoring with:
realpath()canonicalization- Strict root-directory containment checks
- Explicit allowlisting of permitted image locations
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | thorsten/phpmyfaq | ≥ 4.0.0-alpha&&< 4.1.5 | 4.1.5 |
| 🐘Packagist | phpmyfaq/phpmyfaq | ≥ 4.0.0-alpha&&< 4.1.5 | 4.1.5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for thorsten/phpmyfaq. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update thorsten/phpmyfaq to 4.1.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-88g4-74f3-63x9 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-88g4-74f3-63x9 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-88g4-74f3-63x9. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-88g4-74f3-63x9 in your dependencies?
O3 detects GHSA-88g4-74f3-63x9 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.