Search for packages
| purl | pkg:composer/phpmyfaq/phpmyfaq@2.9.0-rc4 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-1qwx-htn1-4bg8
Aliases: CVE-2026-46364 GHSA-289f-fq7w-6q2w |
phpMyFAQ before 4.1.2 contains an unauthenticated SQL injection vulnerability in BuiltinCaptcha::garbageCollector() and BuiltinCaptcha::saveCaptcha() methods that interpolate unsanitized User-Agent headers into DELETE and INSERT queries. Unauthenticated attackers can exploit the public GET /api/captcha endpoint by crafting malicious User-Agent headers to perform time-based blind SQL injection, extracting sensitive data including user credentials, admin tokens, and SMTP credentials from the database. |
Affected by 1 other vulnerability. |
|
VCID-1v6k-n15u-1bcm
Aliases: CVE-2022-3608 GHSA-6rj8-9cm9-6gff |
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.2.0-alpha. |
Affected by 21 other vulnerabilities. |
|
VCID-2na9-t3m7-wfhn
Aliases: CVE-2026-34729 GHSA-cv2g-8cj8-vgc7 |
Affected by 13 other vulnerabilities. |
|
|
VCID-3akv-usbd-53bt
Aliases: CVE-2024-22202 GHSA-6648-6g96-mg35 |
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. phpMyFAQ's user removal page allows an attacker to spoof another user's detail, and in turn make a compelling phishing case for removing another user's account. The front-end of this page doesn't allow changing the form details, an attacker can utilize a proxy to intercept this request and submit other data. Upon submitting this form, an email is sent to the administrator informing them that this user wants to delete their account. An administrator has no way of telling the difference between the actual user wishing to delete their account or the attacker issuing this for an account they do not control. This issue has been patched in version 3.2.5. |
Affected by 26 other vulnerabilities. |
|
VCID-57ev-2w6v-mbbs
Aliases: CVE-2026-24421 GHSA-wm8h-26fv-mg7g |
phpMyFAQ is an open source FAQ web application. Versions 4.0.16 and below have flawed authorization logic which exposes the /api/setup/backup endpoint to any authenticated user despite their permissions. SetupController.php uses userIsAuthenticated() but does not verify that the requester has configuration/admin permissions. Non-admin users can trigger a configuration backup and retrieve its path. The endpoint only checks authentication, not authorization, and returns a link to the generated ZIP. This issue is fixed in version 4.0.17. |
Affected by 0 other vulnerabilities. Affected by 14 other vulnerabilities. |
|
VCID-5pw3-qxh6-6ufr
Aliases: CVE-2026-46366 GHSA-99qv-g4x9-mgc3 |
phpMyFAQ before 4.1.2 contains an information disclosure vulnerability in the getIdFromSolutionId() method that lacks permission filtering, allowing unauthenticated attackers to enumerate restricted FAQ entries and read their titles via the /solution_id_{id}.html endpoint. Attackers can sequentially iterate solution IDs to discover all FAQs including those restricted to specific users or groups, leaking sensitive metadata through redirect Location headers and page canonical links. |
Affected by 1 other vulnerability. |
|
VCID-5wsg-7979-dqgs
Aliases: CVE-2025-62519 GHSA-fxm2-cmwj-qvx4 |
phpMyFAQ is an open source FAQ web application. Prior to version 4.0.14, an authenticated SQL injection vulnerability in the main configuration update functionality of phpMyFAQ allows a privileged user with 'Configuration Edit' permissions to execute arbitrary SQL commands. Successful exploitation can lead to a full compromise of the database, including reading, modifying, or deleting all data, as well as potential remote code execution depending on the database configuration. This issue has been patched in version 4.0.14. |
Affected by 17 other vulnerabilities. |
|
VCID-6jmj-n5mz-bba8
Aliases: CVE-2026-24420 GHSA-7p9h-m7m8-vhhv |
phpMyFAQ is an open source FAQ web application. Versions 4.0.16 and below allow an authenticated user without the dlattachment permission to download FAQ attachments due to a incomprehensive permissions check. The presence of a right key is improperly validated as proof of authorization in attachment.php. Additionally, the group and user permission logic contains a flawed conditional expression that may allow unauthorized access. This issue has been fixed in version |
Affected by 0 other vulnerabilities. Affected by 14 other vulnerabilities. |
|
VCID-7tpb-1avq-zfhu
Aliases: CVE-2026-46361 GHSA-pqh6-8fxf-jx22 |
phpMyFAQ before 4.1.2 contains a stored cross-site scripting vulnerability in search.twig where result.question and result.answerPreview are rendered with the raw filter, disabling autoescape protection. Attackers with FAQ editor privileges can inject HTML-entity-encoded payloads that bypass html_entity_decode(strip_tags()) processing in SearchController.php, executing arbitrary JavaScript in every visitor's browser context including administrators. |
Affected by 1 other vulnerability. |
|
VCID-8k51-budg-h3ak
Aliases: CVE-2026-45007 GHSA-rm98-82fr-mcfx |
phpMyFAQ before 4.1.2 contains missing permission checks in ConfigurationTabController.php where 12 endpoints use userIsAuthenticated() instead of userHasPermission(CONFIGURATION_EDIT). Any authenticated user can enumerate system configuration metadata including permission model, cache backend, mail provider, and translation provider by querying /admin/api/configuration endpoints, violating least privilege access control. |
Affected by 1 other vulnerability. |
|
VCID-a9tb-yj7x-pya1
Aliases: CVE-2026-34728 GHSA-38m8-xrfj-v38x |
phpMyFAQ is an open source FAQ web application. Prior to version 4.1.1, the MediaBrowserController::index() method handles file deletion for the media browser. When the fileRemove action is triggered, the user-supplied name parameter is concatenated with the base upload directory path without any path traversal validation. The FILTER_SANITIZE_SPECIAL_CHARS filter only encodes HTML special characters (&, ', ", <, >) and characters with ASCII value < 32, and does not prevent directory traversal sequences like ../. Additionally, the endpoint does not validate CSRF tokens, making it exploitable via CSRF attacks. This issue has been patched in version 4.1.1. |
Affected by 13 other vulnerabilities. |
|
VCID-cnr9-cykp-bbaw
Aliases: CVE-2023-53929 GHSA-x2v3-9p22-w3x6 |
phpMyFAQ 3.1.12 contains a CSV injection vulnerability that allows authenticated users to inject malicious formulas into their profile names. Attackers can modify their user profile name with a payload like 'calc|a!z|' to trigger code execution when an administrator exports user data as a CSV file. |
Affected by 21 other vulnerabilities. |
|
VCID-ecpv-3xqn-eqf8
Aliases: CVE-2026-46360 GHSA-whqh-9pq5-c7r3 |
phpMyFAQ before 4.1.2 contains a stored cross-site scripting vulnerability in SvgSanitizer::decodeAllEntities() that limits recursive entity decoding to 5 iterations, allowing attackers to bypass sanitization. Authenticated users with FAQ_EDIT permission can upload malicious SVG files with deeply nested ampersand encoding around numeric HTML entities to reconstruct javascript: URLs, which execute arbitrary JavaScript when clicked by other users viewing the uploaded SVG. |
Affected by 1 other vulnerability. |
|
VCID-p68j-sbvd-yuh4
Aliases: CVE-2026-24422 GHSA-j4rc-96xj-gvqc |
phpMyFAQ is an open source FAQ web application. In versions 4.0.16 and below, multiple public API endpoints improperly expose sensitive user information due to insufficient access controls. The OpenQuestionController::list() endpoint calls Question::getAll() with showAll=true by default, returning records marked as non-public (isVisible=false) along with user email addresses, with similar exposures present in comment, news, and FAQ APIs. This information disclosure vulnerability could enable attackers to harvest email addresses for phishing campaigns or access content that was explicitly marked as private. This issue has been fixed in version 4.0.17. |
Affected by 0 other vulnerabilities. Affected by 14 other vulnerabilities. |
|
VCID-qhsm-g24v-k7gj
Aliases: CVE-2026-32629 GHSA-98gw-w575-h2ph |
Affected by 13 other vulnerabilities. |
|
|
VCID-rrz3-kbbd-eyhq
Aliases: CVE-2026-45010 GHSA-9pq7-mfwh-xx2j |
phpMyFAQ before 4.1.2 contains an improper restriction of excessive authentication attempts vulnerability in the /admin/check endpoint, which accepts arbitrary user-id parameters without session binding or rate limiting. Unauthenticated attackers can brute-force any user's six-digit TOTP code by submitting POST requests with sequential token values, bypassing two-factor authentication to gain full administrative access. |
Affected by 1 other vulnerability. |
|
VCID-s9hv-md3j-17hr
Aliases: CVE-2024-22208 GHSA-9hhf-xmcw-r3xg |
phpMyFAQ is an Open Source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. The 'sharing FAQ' functionality allows any unauthenticated actor to misuse the phpMyFAQ application to send arbitrary emails to a large range of targets. The phpMyFAQ application has a functionality where anyone can share a FAQ item to others. The front-end of this functionality allows any phpMyFAQ articles to be shared with 5 email addresses. Any unauthenticated actor can perform this action. There is a CAPTCHA in place, however the amount of people you email with a single request is not limited to 5 by the backend. An attacker can thus solve a single CAPTCHA and send thousands of emails at once. An attacker can utilize the target application's email server to send phishing messages. This can get the server on a blacklist, causing all emails to end up in spam. It can also lead to reputation damages. This issue has been patched in version 3.2.5. |
Affected by 26 other vulnerabilities. |
|
VCID-tpbv-urbk-h7gf
Aliases: CVE-2026-46359 GHSA-pm8c-3qq3-72w7 |
phpMyFAQ before 4.1.2 contains a sql injection vulnerability in CurrentUser::setTokenData that allows authenticated attackers to execute arbitrary SQL by injecting malicious OAuth token claims. Attackers with Azure AD accounts containing SQL metacharacters in display names or JWT claims can break out of string literals and execute arbitrary database queries. |
Affected by 1 other vulnerability. |
|
VCID-txxg-bugj-6bd4
Aliases: CVE-2026-45008 GHSA-gh9p-q46p-57g2 |
phpMyFAQ before 4.1.2 contains a path traversal vulnerability in Client::deleteClientFolder that allows admins with INSTANCE_DELETE permission to delete arbitrary directories. Attackers can submit traversal sequences like https://../../../<path> in the client URL parameter to recursively delete directories outside the intended clientFolder scope. |
Affected by 1 other vulnerability. |
|
VCID-ujpq-qjkp-fygk
Aliases: CVE-2024-24574 GHSA-7m8g-fprr-47fx |
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Unsafe echo of filename in phpMyFAQ\phpmyfaq\admin\attachments.php leads to allowed execution of JavaScript code in client side (XSS). This vulnerability has been patched in version 3.2.5. |
Affected by 26 other vulnerabilities. |
|
VCID-vjqh-59nn-5ude
Aliases: CVE-2026-46363 GHSA-f5p7-2c9q-8896 |
phpMyFAQ before 4.1.2 contains a stored cross-site scripting vulnerability in FAQ creation and update endpoints that bypass sanitization through encode-decode cycles. The vulnerability allows authenticated attackers with FAQ_ADD permission to inject malicious script tags via question or answer parameters, which execute in every visitor's browser when FAQ content is rendered with the raw Twig filter. |
Affected by 1 other vulnerability. |
|
VCID-yckn-74u4-pkaw
Aliases: GHSA-7cx3-2qx2-3g6w |
phpMyFAQ's Missing Authorization on Tag Deletion Allows Any Authenticated User to Delete Tags ## Summary The `TagController::delete()` endpoint at `DELETE /admin/api/content/tags/{tagId}` only verifies that the user is logged in (`userIsAuthenticated()`), but does not check any permission. Any authenticated user — including regular non-admin frontend users — can delete any tag by ID. This contrasts with `TagController::update()` and `TagController::search()`, which both enforce the `FAQ_EDIT` permission. ## Details In `phpmyfaq/src/phpMyFAQ/Controller/Administration/Api/TagController.php`, the `delete()` method (line 121-133) uses only `$this->userIsAuthenticated()`: ```php #[Route(path: 'content/tags/{tagId}', name: 'admin.api.content.tags.id', methods: ['DELETE'])] public function delete(Request $request): JsonResponse { $this->userIsAuthenticated(); // Only checks isLoggedIn() — no permission check $tagId = (int) Filter::filterVar($request->attributes->get('tagId'), FILTER_VALIDATE_INT); if ($this->tags->delete($tagId)) { return $this->json(['success' => Translation::get(key: 'ad_tag_delete_success')], Response::HTTP_OK); } return $this->json(['error' => Translation::get(key: 'ad_tag_delete_error')], Response::HTTP_BAD_REQUEST); } ``` Compare with `update()` (line 48-71) which properly enforces authorization: ```php public function update(Request $request): JsonResponse { $this->userHasPermission(PermissionType::FAQ_EDIT); // Proper permission check // ... also verifies CSRF token ... } ``` The `userIsAuthenticated()` method in `AbstractController` (line 258-263) only checks `$this->currentUser->isLoggedIn()`: ```php protected function userIsAuthenticated(): void { if (!$this->currentUser->isLoggedIn()) { throw new UnauthorizedHttpException(challenge: 'User is not authenticated.'); } } ``` There is no admin-level middleware in the `Kernel` — it registers only RouterListener, LanguageListener, ControllerContainerListener, and exception listeners. The admin API entry point (`admin/api/index.php`) shares the same bootstrap and session as the frontend, meaning a frontend user's session cookie is valid for admin API requests. Additionally, this endpoint lacks CSRF token verification (unlike `update()`), though the primary issue is the missing authorization since the attack vector is a logged-in user acting directly. ## PoC ```bash # Step 1: Register as a regular user on the phpMyFAQ frontend # (or use any existing non-admin authenticated session) # Step 2: As the authenticated non-admin user, delete tag with ID 1: curl -X DELETE 'https://target.com/admin/api/content/tags/1' \ -H 'Cookie: PHPSESSID=<regular_user_session>' # Expected: 401 or 403 (user lacks FAQ_EDIT permission) # Actual: 200 OK with {"success": "..."} # Step 3: Enumerate and delete all tags: for i in $(seq 1 100); do curl -s -X DELETE "https://target.com/admin/api/content/tags/$i" \ -H 'Cookie: PHPSESSID=<regular_user_session>' done ``` ## Impact Any authenticated user (including regular frontend users who registered through the public registration form) can delete all tags in the phpMyFAQ instance. This results in: - **Data integrity loss:** Tags are permanently deleted from the database. All FAQ-to-tag associations are destroyed. - **Disruption of FAQ organization:** Tag-based navigation, filtering, and tag clouds become empty or broken. - **No recoverability without backup:** Deleted tags and their associations cannot be restored without a database backup. The impact is limited to tags (not FAQ content itself), but in large installations with extensive tag taxonomies, this could significantly degrade usability. ## Recommended Fix Add the `FAQ_EDIT` permission check and CSRF token verification to `TagController::delete()`, consistent with `TagController::update()`: ```php #[Route(path: 'content/tags/{tagId}', name: 'admin.api.content.tags.id', methods: ['DELETE'])] public function delete(Request $request): JsonResponse { $this->userHasPermission(PermissionType::FAQ_EDIT); $tagId = (int) Filter::filterVar($request->attributes->get('tagId'), FILTER_VALIDATE_INT); if ($this->tags->delete($tagId)) { return $this->json(['success' => Translation::get(key: 'ad_tag_delete_success')], Response::HTTP_OK); } return $this->json(['error' => Translation::get(key: 'ad_tag_delete_error')], Response::HTTP_BAD_REQUEST); } ``` At minimum, add `$this->userHasPermission(PermissionType::FAQ_EDIT)` to enforce the same authorization as the update and search endpoints. Consider also adding a dedicated `TAG_DELETE` permission type for more granular access control. |
Affected by 1 other vulnerability. |
|
VCID-zr1w-jzzj-a7gd
Aliases: CVE-2026-46362 GHSA-hpgw-ww76-c68r |
phpMyFAQ before 4.1.2 contains an authorization bypass vulnerability in AbstractAdministrationController::userHasPermission() that fails to terminate execution after sending a forbidden response. Attackers can access all permission-protected admin pages by requesting their URLs as authenticated users, exposing admin logs, user data, system information, and application configuration. |
Affected by 1 other vulnerability. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||