CVE Database

Grav API Plugin (Composer package getgrav/grav-plugin-api) before 1.0.10 fails to properly validate the slug field in the POST /pages/{route}/move endpoint. PagesController::move() sanitizes the slug only with ltrim($body['slug'], '.'), which strips leading periods but does not neutralize '/' or '..' segments. An authenticated API caller with the api.pages.write permission can supply path traversal sequences (e.g., 01.home/../../../pwned) to move an entire page directory (content and media) to an arbitrary writable location outside user/pages/, including outside the Grav installation.

Grav API Plugin versions before 1.0.10 fail to restrict write access to security-critical plugin configuration scopes, allowing authenticated users with api.config.write privilege to modify rate limiting and CORS settings. Attackers can disable rate limiting site-wide to enable credential brute-forcing attacks and reconfigure CORS policies to include attacker-controlled origins with credentials enabled.

Grav versions >= 1.7.0 and before 2.0.9 contain a remote code execution vulnerability. FlexDirectory::dynamicDataField() resolves blueprint data-*@: directives by calling call_user_func_array() on attacker-influenced input, validating only that the target is callable (is_callable()) without restricting dangerous functions such as exec, system, passthru, or shell_exec. Because FlexDirectory registers this handler for every Flex directory, it bypasses the validation added to Blueprint::dynamicData() in 2.0.7 (GHSA-fj2p-qj2f-74v5). Any authenticated user with create or update permission on any Flex-based directory (Flex Users, Flex Pages, Flex Objects, or custom Flex types) can execute arbitrary shell commands on the server.

Unauthenticated Cross Site Request Forgery (CSRF) in Popup for CF7 with Sweet Alert <= 1.6.5 versions.

Unauthenticated Cross Site Request Forgery (CSRF) in Kwayy HTML Sitemap <= 4.0 versions.

Shop manager SQL Injection in Persian Woocommerce SMS <= 7.2.2 versions.

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Themeisle Visualizer allows Blind SQL Injection. This issue affects Visualizer: from n/a through 4.0.1.

Unauthenticated Server Side Request Forgery (SSRF) in PeproDev Ultimate Invoice <= 2.2.6 versions.

Unauthenticated Cross Site Scripting (XSS) in Manual - Documentation, Knowledge Base & Education WordPress Theme <= 7.5.4 versions.

Unauthenticated Cross Site Scripting (XSS) in PeproDev Ultimate Invoice <= 2.2.6 versions.

Unauthenticated Broken Access Control in Manual - Documentation, Knowledge Base & Education WordPress Theme <= 7.5.4 versions.

Administrator PHP Object Injection in Complianz <= 7.5.0 versions.

Unauthenticated Broken Access Control in Dokan Pro <= 5.0.3 versions.

Subscriber SQL Injection in Dokan Pro <= 5.0.2 versions.

Subscriber PHP Object Injection in Dokan Pro <= 5.0.2 versions.

Unauthenticated Cross Site Scripting (XSS) in Dokan Pro <= 5.0.0 versions.

Unauthenticated Cross Site Request Forgery (CSRF) in LA-Studio Element Kit for Elementor <= 1.6.2 versions.

Contributor Local File Inclusion in Vino <= 1.9 versions.

Contributor Local File Inclusion in Tonda Core <= 2.1.2 versions.

Administrator SQL Injection in Uncanny Automator <= 7.3.2 versions.

Contributor SQL Injection in Quiz And Survey Master <= 11.2.0 versions.

Contributor SQL Injection in MapSVG <= 8.14.0 versions.

Contributor SQL Injection in MapSVG <= 8.14.0 versions.

In JetBrains IntelliJ IDEA before 2026.2 arbitrary code injection was possible via UI Designer form files

In JetBrains IntelliJ IDEA before 2026.2 unauthorized file access was possible in a Remote Development session

In JetBrains IntelliJ IDEA before 2026.2 arbitrary code execution was possible before granting project trust via development container configuration

In JetBrains PhpStorm before 2026.2 arbitrary code execution was possible before granting project trust via the configured interpreter

In JetBrains PhpStorm before 2026.2 arbitrary code execution was possible before granting project trust via project tooling

In JetBrains WebStorm before 2026.2 arbitrary code execution was possible via a project-supplied linter configuration

In JetBrains WebStorm before 2026.2 arbitrary code execution was possible before granting project trust via the configured Node.js interpreter