PHP: уязвимости стека · Страница 56

Sulu: Used API Keys may be available via Admin API

### Impact The users endpoint controller exposes a project's apiKey field to the logged-in user, provided they have permission for that endpoint. This only has impact if a project itself uses that specific field, Sulu itself does nothing with it and has no authentication per apiKey in its core. ### Patches A patch is released with Version 2.6.23 and 3.0.5. ### Workarounds Remove the field descriptor by patch the UserController.php File in Sulu Security Bundle.

• Обновитесь до 2.6.23
• Обновитесь до 3.0.6

phpMyFAQ - Stored XSS via Utils::parseUrl() in Comment Rendering

phpMyFAQ before 4.1.2 contains a stored cross-site scripting vulnerability in Utils::parseUrl() that allows authenticated users to inject JavaScript via malformed URLs in comments. Attackers can craft URLs with unescaped quotes to inject event handlers, stealing admin session cookies and achieving full application takeover when visitors view affected FAQ pages.

• Обновитесь до 4.1.2

phpMyFAQ - Unauthenticated Information Disclosure via getIdFromSolutionId Permission Bypass

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.

• Обновитесь до 4.1.2

phpMyFAQ - Missing Authorization in Tag Deletion Endpoint

phpMyFAQ before 4.1.2 contains a missing authorization vulnerability in the DELETE /admin/api/content/tags/{tagId} endpoint that allows any authenticated user to delete tags. Any logged-in user, including regular frontend users, can delete arbitrary tags by sending a DELETE request with a valid session cookie, resulting in permanent data loss and disruption of FAQ organization.

• Обновитесь до 4.1.2

phpMyFAQ - SQL Injection via User-Agent Header in BuiltinCaptcha

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.

• Обновитесь до 4.1.2

phpMyFAQ - Stored XSS in FAQ Question/Answer via Encode-Decode Bypass

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.

• Обновитесь до 4.1.2

phpMyFAQ - Authorization Bypass in Admin Pages via Non-Terminating Permission Check

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.

• Обновитесь до 4.1.2

phpMyFAQ - Stored Cross-Site Scripting via raw Filter in search.twig

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.

• Обновитесь до 4.1.2

phpMyFAQ - Stored XSS via Entity Decoding Depth Limit Bypass in SVG Sanitizer

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.

• Обновитесь до 4.1.2

phpMyFAQ - SQL Injection in CurrentUser::setTokenData via Unescaped OAuth Token Fields

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.

• Обновитесь до 4.1.2

phpMyFAQ - Unauthenticated Two-Factor Authentication Brute-Force via /admin/check Endpoint

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.

• Обновитесь до 4.1.2

phpMyFAQ - Insufficient Authorization Check in Admin API Endpoints

phpMyFAQ before 4.1.2 contains an insufficient authorization vulnerability in admin-api routes that allows authenticated ordinary users to access administrative endpoints by only checking login status instead of verifying backend privileges. Attackers with valid frontend user accounts can access sensitive backend operational information including dashboard versions, LDAP configuration, Elasticsearch statistics, and health-check data.

• Обновитесь до 4.1.2

phpMyFAQ - Path Traversal in Client::deleteClientFolder via URL Parameter

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.

• Обновитесь до 4.1.2

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

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.

• Обновитесь до 4.1.2

Magento LTS: Open Redirect via Unvalidated `uenc` Parameter in `stockAction()` - magento-lts

Magento Long Term Support (LTS) is an unofficial, community-driven project provides an alternative to the Magento Community Edition e-commerce platform with a high level of backward compatibility. Prior to 20.18.0, Mage_ProductAlert_AddController::stockAction() reads the uenc query parameter and passes it directly to $this->_redirectUrl($backUrl) without calling $this->_isUrlInternal(). When the supplied product_id does not match any catalog product, the server issues an unvalidated HTTP 302 redirect to whatever URL was provided as uenc. This vulnerability is fixed in 20.18.0.

• Обновитесь до 20.18.0

Magento LTS: Weak API Session ID — Predictable MD5 of Time-Derived Inputs

Magento Long Term Support (LTS) is an unofficial, community-driven project provides an alternative to the Magento Community Edition e-commerce platform with a high level of backward compatibility. Prior to 20.18.0, the XML-RPC / SOAP API session ID is generated using an outdated, time-based construction rather than a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). All inputs to the MD5 hash are time-derived and non-secure. Because the resulting digest relies entirely on the timestamp and the PHP internal LCG state, the effective entropy is severely constrained. This violates the OWASP ASVS v4 requirement of ≥ 64 bits of entr

• Обновитесь до 20.18.0

Magento LTS: Reflected XSS - Import -> Data Flow (profiles)

Magento Long Term Support (LTS) is an unofficial, community-driven project provides an alternative to the Magento Community Edition e-commerce platform with a high level of backward compatibility. Prior to 20.18.0, there is a reflected XSS vulnerability under admin panel -> System -> Import/Export -> Dataflow - Profiles. This vulnerability is fixed in 20.18.0.

• Обновитесь до 20.18.0

Cockpit CMS 2.14.0 Stored XSS via Set Field Display Template

Cockpit CMS through version 2.14.0, patched in commit 72a83fc, contains a stored cross-site scripting vulnerability in the Set field type's Display template option, where the template string is processed by the $interpolate function using new Function() and rendered via Vue's v-html directive without sanitization. An attacker with content/:models/manage permission can inject arbitrary JavaScript into the Display template, which executes in the browser of any user viewing the collection items list.

PrestaShop: Stored XSS executable in customer service view

PrestaShop is an open source e-commerce web application. Prior to 8.2.6 and 9.1.1, there is a stored Cross-Site Scripting (XSS) vulnerability in the PrestaShop back-office Customer Service view. An unauthenticated attacker can submit the public Contact Us form with a malicious email address. The payload is stored in the database and executed when a back-office employee opens the affected customer thread, enabling session hijacking and full back-office takeover. This vulnerability is fixed in 8.2.6 and 9.1.1.

• Обновитесь до 8.2.6
• Обновитесь до 9.1.1

Flight: Sensitive information disclosure via default error handler in flightphp/core

Flight is an extensible micro-framework for PHP. Prior to 3.18.1, the default error handler Engine::_error() writes the full exception message, exception code, and stack trace (including absolute filesystem paths) directly into the HTTP 500 response, with no debug gating. Production deployments leak internal paths, any secret interpolated into an exception message, and full module structure — giving attackers primitives for chaining other weaknesses (LFI, path traversal). This vulnerability is fixed in 3.18.1.

• Обновитесь до 3.18.1