Veille CVE

Mardi 16 juin 2026

2 CVE

Critique 0 Élevée 1 Moyenne 1 Faible 0 Non évaluée 0 Exploitées (KEV) Tri : plus récentes « Php php » ✕
  1. CVE-2026-6933 8.8 Élevée

    Premmerce Dev Tools

    The Premmerce Dev Tools plugin for WordPress is vulnerable to Remote Code Execution via missing authorization in versions up to and including 2.0. This is due to the 'generatePluginHandler' function lacking any authorization check before processing user-supplied POST data, combined with the 'createFromStub' function performing unsanitized string substitution of the 'premmerce_plugin_namespace' parameter directly into PHP stub files written to the wp-content/plugins/ directory. An attacker can inject a semicolon followed by arbitrary PHP code into the namespace parameter, causing the generated plugin file to contain and execute that code when accessed via HTTP. This makes it possible for authenticated attackers with Subscriber-level access and above to create arbitrary PHP files on the server and achieve remote code execution.

  2. CVE-2026-48157 6.1 Moyenne

    slimphp Slim

    Slim is a PHP micro framework that enables users to write simple web applications and APIs. In versions 4.4.0 through 4.15, if an application uses HttpException::setTitle() and/or setDescription() to include untrusted/request-derived data in the error title or description (e.g. "No products found matching '{$query}'."), an attacker could inject arbitrary HTML/JavaScript that executes in the victim's browser when they encounter an HTML error page generated by Slim. The vulnerability is present even with displayErrorDetails = false as the unescaped title and description are rendered on this error path. Built-in exceptions (HttpNotFoundException, HttpBadRequestException, etc.) ship plain-text defaults, so a vanilla Slim app with no user code is not exploitable. Only applications that feed untrusted data into setTitle() and/or setDescription() are affected. The issue has been fixed in 4.15.2. If developers are unable to immediately update their applications, they can work around this issue by avoiding passing untrusted/request-derived data into HttpException::setTitle() and setDescription() and using static, plain-text error copy instead. They should also register a custom error renderer (an ErrorRendererInterface implementation, or a subclass of HtmlErrorRenderer that escapes the title and description) for the HTML media type.