CVE-2026-75865
The WPLP Cookie Consent – Cookie Banner & Consent Management for GDPR, CCPA & Google Consent Mode plugin for WordPress is vulnerable to arbi
CVSS
9.8
Crítico
EPSS
—
KEV
—
Exploit Today
—
0-100
Publicado: 1 sept 2026 · Última mod.: 1 sept 2026 · CWE-434
Sin historial EPSS suficiente todavía.
The WPLP Cookie Consent – Cookie Banner & Consent Management for GDPR, CCPA & Google Consent Mode plugin for WordPress is vulnerable to arbitrary file upload due to missing file type validation in the saas_upload_logo() function combined with an authorization bypass on the WPLP connector REST endpoints in all versions up to, and including, 4.4.1. This makes it possible for unauthenticated attackers to upload arbitrary files on the affected site's server which may make remote code execution possible.
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-195138.1 ALT—
———The Gravity Forms plugin for WordPress is vulnerable to Arbitrary File Upload in all versions up to, and including, 3.0.2. This is due to insufficient validation of multi-file upload chunk state in the `GFAsyncUpload::upload()` function, where public form state URL hashes can be reused as chunk continuation hashes and attacker-controlled temporary filenames are accepted before sanitization. This makes it possible for unauthenticated attackers, when a public form contains a File Upload field with Multiple Files enabled, to upload a valid PNG/PDF polyglot to an attacker-selected public `.php` or `.html` filename in the Gravity Forms temporary upload directory. This can lead to remote code execution on WordPress systems that use NGINX or other non `.htaccess` respecting web servers. NOTE: During installation and activation, the Gravity Forms plugin places a `.htaccess` file in this directory, which prevents this vulnerability from being exploited despite the PHP file being written to the temporary upload directory. In these cases where PHP execution is blocked, attacker-written HTML can result in stored same-origin cross-site scripting if a victim visits the generated file URL.5hCVE-2026-84147——
———This vulnerability exists in the ERP system due to improper authentication controls and inadequate file type validation at the API endpoint. An unauthenticated remote attacker could exploit this vulnerability by uploading arbitrary files to a web accessible directory on the targeted system
Successful exploitation of this vulnerability could allow the attacker to execute arbitrary code and compromise the targeted system.10hCVE-2026-829217.3 ALT—
———A weakness has been identified in ShopEx ECShop up to 2.5.1. This affects the function check_img_type of the file admin/pack.php. Executing a manipulation of the argument pack_img can lead to unrestricted upload. It is possible to launch the attack remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.5hCVE-2026-818918.1 ALT—
———elFinder is an open-source file manager for web, written in JavaScript using jQuery UI. Prior to 2.1.70, checkExtractItems() in php/elFinderVolumeDriver.class.php calls mimetypeInternalDetect() without passing the result through mimeTypeNormalize(). Because the .phtml, .phar, .php5, and .php3 extensions are absent from mime.types, the staticMimeMap entries that map them to text/x-php are not applied, and allowPutMime() permits extraction even when uploadDeny blocks text/x-php. An attacker with ZIP upload permission can extract PHP-executable files into a web-accessible files/ directory and achieve remote code execution when the server executes those extensions. This issue is fixed in version 2.1.70.11hCVE-2026-8178010.0 CRÍ—
———Unauthenticated Arbitrary File Upload in Hash Form <= 1.4.2 versions.5hCVE-2026-541794.4 MED—
———backpack/crud provides Create, Read, Update & Delete (CRUD) functions for Backpack, a collection of Laravel packages that help users build custom administration panels. From 6.0.0 until 6.8.14 and 7.0.37, the src/app/Library/Uploaders/SingleBase64Image.php methods SingleBase64Image::uploadFiles and SingleBase64Image::uploadRepeatableFiles, used by image fields through withFiles(), accept any data URI beginning with data:image without validating the declared MIME subtype or decoded bytes, while src/app/Library/Uploaders/Support/FileNameGenerator.php method FileNameGenerator::getExtensionFromFile applies mime_content_type() to the data URI instead of the decoded content. An authenticated administrator can therefore store arbitrary file content under an extensionless filename on the configured disk, which can cause stored cross-site scripting or other unintended behavior when the file is served and accessed. This issue is fixed in version 7.0.38 and 6.8.14.11h