Tag1 D7ES Security Advisories

The `drd_agent` module builds a `.phar` filename from the attacker-controlled `HTTP_X_DRD_VERSION` request header, fetches it over HTTPS, writes it to `temporary://`, and `require_once`s it, all with no authentication, signature, or secret check before the inclusion, allowing an unauthenticated attacker to influence the included path. Because the fetch is over HTTPS from a trusted host, standalone code execution is not achievable; chaining to remote code execution requires an additional precondition (a separate file-write primitive that plants a `.phar`, or compromise of the trusted host).

The Notify module renders node titles, comment subjects, and subscriber email addresses in its admin forms without HTML-encoding, allowing an authenticated user to inject arbitrary JavaScript that executes in an administrator's browser.

The module's "secret word" check on the account registration form had no rate limiting, allowing an anonymous attacker to repeatedly guess the shared secret word and bypass the spam-prevention gate.

The performance-report download and report-generation menu routes are configured with an access callback that unconditionally grants access to every user, silently voiding the permissions those routes were meant to require and allowing an anonymous user to download stored performance-profiling reports.

The Nodequeue module outputs subqueue titles on the admin subqueue listing page without HTML-encoding them, allowing a stored XSS payload embedded in a subqueue title (or in a taxonomy term name used by the Smartqueue sub-module) to execute arbitrary JavaScript in an administrator's browser.

The Salesforce Suite module did not generate or validate an anti-CSRF `state` token during the OAuth 2.0 authorization handshake, allowing an attacker to forge the authorization callback and bind the Drupal site to an attacker-controlled Salesforce account.

The `favorites` module stored anonymous users' favorites in an unsigned client cookie and unserialized the attacker-controlled cookie body with no restriction on allowed classes, allowing an unauthenticated attacker (on a site where anonymous users may manage favorites) to instantiate arbitrary PHP objects (PHP Object Injection) and, with a suitable POP gadget chain, achieve remote code execution.

The BOTCHA Spam Prevention module fails to sanitize the recipe book title before output, both as the page title on the recipe book edit page and in the recipe book listing, allowing a user who can configure BOTCHA to inject arbitrary HTML/JavaScript that executes when either page is viewed.

The BOTCHA module shipped a hardcoded, publicly-known default secret that was used as a fallback on sites where `botcha_secret` had never been set. Because BOTCHA's per-form tokens are derived from this secret, an attacker who knows the value can compute valid challenge responses and bypass bot protection on any affected form. Only sites installed before August 2013 are affected. `hook_install()` has generated a random site-unique secret since that date, so any installation or reinstallation since then is not vulnerable.

The Node Form Settings module failed to HTML-escape the node title when inserting it into custom form page titles, allowing a user with content creation permissions to inject arbitrary HTML into the edit and delete node form pages viewed by other users.