PAT-001
CríticaWebshell eval+base64
Webshell clásico que decodifica código PHP ofuscado en runtime.
eval(base64_decode(gzinflate(Backdoor · 95%quarantine
Intel Center
Inteligencia de amenazas. Compartida, no privada.
Todo patrón que detectamos defendiendo un sitio entra al knowledge base público. Todos los sitios protegidos lo aprovechan al mismo tiempo. Base curada del snapshot 2026-08-12 + señales en vivo de la red Drokio.
10Patrones activos
1625CVEs rastreados
1650Threats (24h)
4Fuentes activas
Señales de la red
Señales en vivo de la red
Telemetría anonimizada de los sitios protegidos: familia del ataque, severidad, país de origen y módulo que lo bloqueó. Nunca IPs, contenido ni identidad de los sitios.
El motor durable de señales está en proceso de activación. Esta sección se ilumina sola con los bloqueos reales de la red apenas quede encendido — sin esperar un redeploy. Mientras tanto, abajo está la base curada de patrones y CVEs.
Patrones de detección
Top 6 patrones en vigilancia
Cada pattern es una firma lógica (conjunto de indicators) que el scanner evalúa contra cada archivo y request. Confianza expresada 0–1; acción automática al disparar.
PAT-003
CríticaSkimmer de checkout WooCommerce
JavaScript que exfiltra datos de tarjeta desde el checkout.
fetch(XMLHttpRequestinput[name="card"]document.addEventListener('submit'Skimmer · 92%quarantine
PAT-006
CríticaCreación de usuario admin oculto
Creación programática de cuenta con rol administrator.
wp_insert_useradministratoruser_passpersistence · 88%quarantine
PAT-004
CríticaEjecución OS desde PHP
Invocación directa a comandos del sistema operativo.
shell_exec(passthru(system(`$RCE · 85%quarantine
PAT-010
AltaInclude dinámico (LFI/RFI)
Inclusión de archivo controlado por input externo.
include($require($include $_require $_LFI · 90%quarantine
PAT-009
AltaExfiltración vía wp_remote_post
POST saliente con datos codificados — posible exfiltración.
wp_remote_post(base64_encode(\$_POSTexfiltration · 82%flag
CVEs críticos
Vulnerabilidades con exploit público
Subconjunto filtrado por severidad crítica o exploit disponible. Todas se usan para reforzar las reglas de detección en los sitios protegidos.
| CVE | Componente | Severidad | Exploit | Fuentes | Publicado |
|---|---|---|---|---|---|
| CVE-2026-63223 | codeigniter4/framework | Crítica | disponible | GitHub Advisory | 07 ago 2026 |
| CVE-2026-63222 | codeigniter4/framework | Alta | disponible | GitHub Advisory | 07 ago 2026 |
| CVE-2026-63221 | codeigniter4/framework | Crítica | disponible | GitHub Advisory | 07 ago 2026 |
| CVE-2026-63220 | codeigniter4/framework | Media | disponible | GitHub Advisory | 07 ago 2026 |
| CVE-2026-54164 | api-platform/core | Media | disponible | GitHub Advisory | 07 ago 2026 |
| CVE-2026-62996 | smarty/smarty | Media | disponible | GitHub Advisory | 07 ago 2026 |
| CVE-2026-62992 | smarty/smarty | Media | disponible | GitHub Advisory | 07 ago 2026 |
| CVE-2026-67434 | squizlabs/php_codesniffer | Alta | disponible | GitHub Advisory | 06 ago 2026 |
Resumen diario
Últimas 24 horas · 12 ago 2026
Volumen recopilado de las fuentes activas, desglosado por origen y severidad.
Por fuente
- NVD20 · 50%
- GitHub Advisory20 · 50%
- URLhaus0 · 0%
- WPScan0 · 0%
Por severidad
- Media16 · 40%
- Alta16 · 40%
- Crítica6 · 15%
- Baja2 · 5%
Feed reciente
Últimas 10 amenazas recopiladas
Dump crudo del último threat-collector run. También disponible en RSS — /intel/feed.xml.
- GitHub Advisory07 ago 2026CríticaGHSA-mmj4-63m4-r6h5
CodeIgniter: Uploaded file extension validation bypass in `is_image` and `mime_in` rules
### Impact This is an unsafe file upload validation vulnerability that can lead to remote code execution in vulnerable application configurations. Applications are impacted when they: - validate uploads using `is_image` or `mime_in` without an independent safe extension check, such as `ext_in` on patched versions - save uploaded files using the client-supplied filename - place uploads in a web-accessible directory where PHP files can execute ### Patches Upgrade to v4.7.4 or later. ### Workarounds - Save uploads outside the public web root, preferably under `writable/uploads`. - Use `$file->store()` or `$file->move($path, $file->getRandomName())` instead of preserving the original client filename. - Disable script execution in any public upload directory. - Manually verify the client filename extension before moving the file. - For image uploads, reject files when `$file->getClientExtension()` is not an allowed image extension. - For exact MIME-type validation, reject files when `$file->getClientExtension()` does not match `$file->guessExtension()`.
Ver fuente → - GitHub Advisory07 ago 2026AltaGHSA-hhmc-q9hp-r662
CodeIgniter: Path traversal in UploadedFile::move() when using client-provided filenames
### Impact In affected versions, calling `UploadedFile::move()` **without a second argument** uses the client-provided filename without sanitization. Depending on the destination path and server configuration, an attacker can supply a filename containing path traversal sequences (e.g. `../../public/shell.php`) to write uploaded content outside the intended upload directory. The patch sanitizes this default (no-argument) path. **Note:** The patch only sanitizes the filename when no second argument is passed. If your application **explicitly** passes a client-provided name as the second argument, you remain responsible for sanitizing it - the patch does not (and cannot) sanitize a caller-supplied filename: ```php // Unsafe - even after upgrading: $file->move(WRITEPATH . 'uploads', $file->getName()); $file->move(WRITEPATH . 'uploads', $file->getClientName()); ``` ### Patches Upgrade to v4.7.4 or later. ### Workarounds If you cannot upgrade immediately, use a generated filename or sanitize the client filename before passing it to `move()`. Use a generated filename: ```php $file->move(WRITEPATH . 'uploads', $file->getRandomName()); ``` Or sanitize the client filename before passing it to `move()`: ```php helper('security'); $name = sanitize_filename($file->getClientName()); $file->move(WRITEPATH . 'uploads', $name); ```
Ver fuente → - GitHub Advisory07 ago 2026CríticaGHSA-c9w5-rwh3-7pm9
CodeIgniter: SQL injection in Query Builder deleteBatch() when used with where() conditions
### Impact A SQL injection vulnerability exists in the Query Builder's `deleteBatch()` method. When `deleteBatch()` is used together with `where()` conditions, the bound values from the `WHERE` clause are substituted directly into the generated SQL **with their escape flag ignored**, so they are never escaped or quoted. If an application passes user-controlled input to `where()` before calling `deleteBatch()`, that input is interpreted as SQL rather than as a value, allowing SQL injection. This affects only the `deleteBatch()` code path. Regular `delete()` operations escape `where()` binds correctly. ### Patches Upgrade to v4.7.4 or later. ### Workarounds If you cannot upgrade immediately: - Strictly validate and cast values (e.g. numeric IDs) before using them in conditions - though this does not fully protect string conditions. - Do not pass user-controlled input to `where()` when using `deleteBatch()`. - For user-controlled conditions, use a normal `delete()` with Query Builder binds instead of `deleteBatch(`). - Where possible, express required matching values through the batch data and `onConstraint()` rather than as separate user-controlled `where()` clauses.
Ver fuente → - GitHub Advisory07 ago 2026MediaGHSA-7wmf-pw8j-mc78
CodeIgniter: Spoofable forwarded HTTPS headers in IncomingRequest::isSecure()
### Impact `IncomingRequest::isSecure()` trusted the `X-Forwarded-Proto` and `Front-End-Https` headers from any incoming request. In affected deployments, an attacker could spoof these headers and cause the application to incorrectly treat an HTTP request as secure. This may impact applications that rely on `isSecure()`, `force_https()`, `forceGlobalSecureRequests`, or similar logic to enforce HTTPS-only access or make security-sensitive decisions. Exploitability depends on deployment configuration. Applications are most exposed if the backend is reachable directly over HTTP, or if a reverse proxy/load balancer forwards client-supplied forwarding headers without stripping or overwriting them. ### Patches Upgrade to v4.7.4 or later. ### Workarounds Users who cannot upgrade immediately should enforce HTTP-to-HTTPS redirects outside CodeIgniter, for example with Apache `.htaccess`/virtual host rules, nginx server blocks, Caddy site config, or load balancer redirect rules. Users should also ensure that reverse proxies strip or overwrite client-supplied `X-Forwarded-Proto` and `Front-End-Https` headers before forwarding requests to the application.
Ver fuente → - GitHub Advisory07 ago 2026MediaGHSA-9rjg-x2p2-h68h
API Platform Core: Relation IRIs are not type-checked: a related resource can be denormalised as the wrong resource type (type confusion)
## Summary The API Platform serializer's `AbstractItemNormalizer` does not validate the resource type returned when resolving relation IRIs, allowing type confusion where a resource of an unintended type can be silently assigned to a relation property. ## Impact An attacker who can submit write requests (POST/PUT/PATCH) to an API Platform endpoint with writable relations can supply a relation IRI pointing to a resource of a different type than the relation's declared class. Because `getResourceFromIri()` does not pass an `$operation` to `IriConverter::getResourceFromIri()`, the `is_a` type guard at `IriConverter.php:86` is skipped. For untyped relation properties (legacy `@var`-only style), the wrong-typed object is silently assigned, corrupting invariants and potentially feeding downstream logic that assumes the declared type (CWE-843). For typed properties (modern PHP 8.x), the substitution is blocked by Symfony's PropertyAccessor with an `InvalidTypeException`. ## Affected versions - `api-platform/core` `< 4.1.30` - `api-platform/core` `>= 4.2.0, < 4.2.26` - `api-platform/core` `>= 4.3.0, < 4.3.12` Older major series (`2.x`, `3.x`) ship the same vulnerable code path and are end-of-life; no fix is planned. ## Patched versions - `4.1.30` - `4.2.26` - `4.3.12` ## Fix An `is_a` guard is added inside `AbstractItemNormalizer::getResourceFromIri()` (and the equivalent inline call sites on 4.1) so that a mismatched IRI throws `InvalidArgumentException`, mirroring the operation-aware check the `IriConverter` already performs when an operation is supplied. This forces a `400 Bad Request` response for cross-type IRIs instead of a silent assignment. ## Workarounds Declare a PHP type on every writable relation property (e.g. `public ?Foo $relation = null;` instead of `@var Foo $relation`). Symfony's `PropertyAccessor` will then reject a mismatched object with `InvalidTypeException`. This does not cover collections of mixed-type interfaces; upgrading to a patched v
Ver fuente → - GitHub Advisory07 ago 2026MediaGHSA-rjhh-76wf-8xmw
Smarty Security stream restriction bypass through stream: resource
`smarty/smarty` version `5.8.0` can read local files through PHP stream wrappers even when Smarty Security is enabled and all streams are disabled with `Security::$streams = null`. The bypass uses Smarty's built-in `stream:` resource type. A template such as: ```smarty {include file="stream:php://filter/read=convert.base64-encode/resource=/tmp/secret.tpl"} ``` is handled as Smarty resource type `stream`, so the security check that would normally reject the underlying `php` wrapper is not applied. `StreamPlugin` then opens the nested `php://filter/...` URI directly. For comparison, the direct resource: ```smarty {include file="php://filter/read=convert.base64-encode/resource=/tmp/secret.tpl"} ``` is blocked with `stream 'php' not allowed by security setting`. Affected package: - Ecosystem: Packagist / Composer - Package: `smarty/smarty` - Confirmed affected version: `5.8.0` - Confirmed source reference from Composer lock: `78d259d3b971c59a0cd719c270cc5cbb740c36a7` - Current stable version on Packagist at review time: `v5.8.0` - Packagist usage at review time: 41,113,855 total downloads and 840,604 monthly downloads Relevant code paths: - `Smarty\Resource\BasePlugin::load(...)` - `Smarty\Resource\StreamPlugin::getContent(...)` - `Smarty\Security::isTrustedStream(...)` `BasePlugin::load()` maps the built-in resource name `stream` directly to `StreamPlugin` before the code path that checks PHP stream wrappers with `stream_get_wrappers()` and `Security::isTrustedStream($type)`. `StreamPlugin::getContent()` later calls `fopen($filepath, 'r+')` on the nested URI when the resource name contains `://`. Preconditions: An application must render templates that are not fully trusted while relying on Smarty Security to restrict local files and PHP stream wrappers. The PoC sets: ```php $smarty->enableSecurity(); $smarty->security_policy->streams = null; ``` Local reproduction: The PoC creates a disposable template directory and a separate outside directory. It ena
Ver fuente → - GitHub Advisory07 ago 2026MediaGHSA-f6wf-28g6-769x
Smarty: Symlink path traversal out of trusted directories
When Smarty's Security policy is enabled, secure_dir (and the configured template/trusted directories) restrict which local files a template may read via {include} and {fetch}. The trust check in Security::_checkDir() resolved the requested path with Smarty::_realpath(), which normalizes the path as a string only and does not follow symbolic links. A symlink placed inside a trusted directory therefore passed the trust check, while the underlying file_get_contents() followed it to an arbitrary file outside the sandbox (e.g. /etc/passwd). ## Impact An attacker able to (a) cause a symlink to exist inside a trusted directory (e.g. a user-upload area located within the template path) and (b) cause a template to reference that path can read arbitrary files readable by the PHP process, escaping the secure_dir boundary. Confidentiality impact only. ## Patches Fixed in 5.8.2. Security::_checkDir() now resolves the requested file with native realpath() and re-validates the canonical, symlink-free path against the trusted directories (which are canonicalized the same way, so legitimate symlinked deployment paths such as a Capistrano current symlink or macOS /var → /private/var keep working). It falls back to string normalization only when the file does not yet exist on disk. ## Workarounds Ensure no untrusted symlinks can be created within any directory listed in secure_dir/the trusted template directories; restrict write access to those directories to trusted processes only. ## References - Fix commit: 99c048c - CWE-22
Ver fuente → - GitHub Advisory07 ago 2026CríticaGHSA-wg23-69c2-gjc8
Craft CMS: Passkey login accepts replayed WebAuthn assertions
Craft CMS passkey login accepts WebAuthn requestOptions from the unauthenticated login request body and does not persist the updated credential counter returned by the WebAuthn assertion validator. A captured passkey login request body can therefore be replayed because the old challenge is accepted again, and the stored credential counter remains stale. Craft CMS 5.10.3 and current `5.x` HEAD accept `PublicKeyCredentialRequestOptions` from the unauthenticated `users/login-with-passkey` request body and do not persist the updated `PublicKeyCredentialSource` returned/mutated by `web-auth/webauthn-lib` after assertion validation. As a result, a captured passkey login request body is not one-time-use. Reposting the same `requestOptions` and `response` can result in validation against the same stale credential counter and create another Craft session for that user. This weakens passkeys from a fresh, server-challenged authentication ceremony into a replayable bearer artifact if one successful assertion body is exposed. ## Attack Scenario 1. A victim successfully logs in with a passkey. 2. The `POST /actions/users/login-with-passkey` body containing `requestOptions` and `response` is captured from an application/request log, debugging proxy, browser extension, compromised analytics layer, or another request-body disclosure point. 3. The attacker reposts the same body to `users/login-with-passkey`. 4. Craft deserializes the attacker-supplied `requestOptions`, so the old challenge remains accepted for validation. 5. The WebAuthn validator compares the assertion's `signCount` against the stale stored credential counter. 6. Because Craft did not persist the updated credential source on the original login, the same stale stored counter is used again. 7. The same captured assertion validates and Craft creates another authenticated session for the victim account. This is exactly what WebAuthn's challenge and signature-counter lifecycle is meant to prevent: a successful ass
Ver fuente → - GitHub Advisory06 ago 2026MediaGHSA-957r-qf9p-67xw
Craft CMS: Arbitrary file read via SplFileObject in non-sandboxed template contexts
The `create()` Twig function (introduced in 5.9.0) allows instantiation of arbitrary PHP classes from template code, restricted only by a 5-entry blocklist. `SplFileObject` is not in the blocklist, enabling arbitrary file read, including `.env` (security key, DB credentials) and the passwd file from non-sandboxed Twig template contexts, such as entry type title formats and URI formats. The sandbox correctly blocks `create()` in system email templates, so this finding applies only to admin-configured, non-sandboxed contexts that require `allowAdminChanges=true`. ## Prerequisites - Admin access to the Craft control panel - `allowAdminChanges` must be `true` (default in dev/staging, recommended `false` in production) - Admin must be able to edit entry type settings (title format, URI format) - Any user who subsequently creates an entry in the affected section triggers the file read ## Limitations - Requires admin-level access: not exploitable by low-privilege users - `allowAdminChanges` must be `true`: production best practices recommend `false`, which prevents entry type configuration changes - Per Craft’s own severity guidelines, findings requiring `allowAdminChanges=true` are rated low - The `create()` function is blocked by the Twig sandbox, so this cannot be exploited via system email templates or any other sandboxed context ## Impact An admin user (or an attacker who has compromised an admin account) can read arbitrary files from the server filesystem by setting a malicious entry type title format using `create('SplFileObject', ['/path/to/file'])`. In production environments, this exposes `.env` files containing the `CRAFT_SECURITY_KEY`, database credentials, API keys, and other secrets. The file contents are rendered as entry titles visible to any user with permission to view entries in the affected section. The impact is limited by the requirement for admin access and `allowAdminChanges=true`.
Ver fuente → - GitHub Advisory06 ago 2026MediaGHSA-596p-6jv8-775v
Craft CMS: Authenticated leak of secret environment variables
Environment variables and secrets are interpolated into a Twig template even when the Twig sandbox is enabled, allowing them to be leaked by an authenticated attacker. The Craft vulnerability [CVE-2026-31857](https://github.com/craftcms/cms/security/advisories/GHSA-fp5j-j7j4-mcxc) was only patched by applying sandboxed Twig templating. This theoretically protects Craft CMS against RCE attacks, provided the sandbox is enabled and secure, with no known bypasses. However, the same request parameter `elementId,` which allows for sandboxed Twig templates to be rendered, also includes functionality that interpolates referenced environment variables. If the parameter includes a string of the form `${ENV_VAR}` then the string is replaced with the environment variable or secret from a secrets file with that name. Afterward, the string is rendered as a Twig template. If the sandbox is disabled, Twig templates can already gain RCE or access environment variables using the getenv function. Sandboxed Twig templates should not have this access, but now do thanks to this additional environment-variable replacement behavior. The template’s resulting value is not directly reflected in the response. To exfiltrate the value, the sandboxed Twig template cannot use network functions. But it can use a blind error-based approach similar to blind SQL injection. With enough requests, any environment variable or secret can be incrementally leaked. This can be abused to forge a session, escalate privileges with the `CRAFT_SECURITY_KEY`, and steal credentials for the database, SMTP server, or other connected APIs or blob storage. ## Impact An authenticated attacker, with permission to access the control panel, can render a malicious Twig template and steal arbitrary environment variables and secrets with a large number of requests, even if the Twig sandbox is enabled through `enableTwigSandbox()`.
Ver fuente →
Paso 1
Recolectamos
Cada 24h el pipeline lee NVD, GitHub Advisory, WPScan y URLhaus. Feedback de sitios Drokio entra al mismo lago.
Paso 2
Consolidamos
Pasos de deduplicación + clustering por plugin. Patrones emergen cuando una señal se repite en N sitios.
Paso 3
Distribuimos
Snapshot público acá + prompt RAG para Drako. Cada sitio protegido ve la misma inteligencia al mismo tiempo.
Tu sitio merece un guardián que nunca duerme.
Mientras leés esto, hay bots escaneando sitios WordPress buscando vulnerabilidades. Drako está listo para defender el tuyo.
7 días de garantía · Cancelá cuando quieras · Soporte WhatsApp