Symfony Twig sandbox policy bypass enables information disclosure

A sandbox information disclosure exists in Twig before 1.38.0 and 2.x before 2.7.0 because, under some circumstances, it is possible to call the __toString() method on an object even if not allowed by the security policy in place.

• Twig 1.x: versions 1.0.0 through 1.37.1 are affected; the vendor advisory states that the issue is fixed in 1.38.0.
• Twig 2.x: versions 2.0.0 through 2.6.2 are affected; the vendor advisory states that the issue is fixed in 2.7.0.
• Debian stretch, represented as Debian Linux 9.0 in the record: the twig package is fixed in 1.24.0-2+deb9u1. The status of unlisted later or parallel branches is not established by the available evidence and should be checked separately.

Twig sandbox mode evaluates non-trusted templates under an allowlist policy covering tags, filters, functions, and method calls. PHP can implicitly cast an object to a string during output and other expression handling, which invokes __toString(). Twig blocked the simple direct-print case, but the vendor advisory identifies indirect cases where the conversion still occurred, including use through a filter such as upper; the patch also covers implicit conversions from concatenation, filters, functions, and related expression handling. The weakness is an authorization-policy bypass for string conversion, with information disclosure as the consequence. Exploitation requires the application to use sandbox mode and expose a reachable path that evaluates relevant template input; whether an external party can control or influence that input is application-specific. The exact class, object state, and disclosed fields are not established by the record.

• The supplied exploitation metadata records network reachability, no authentication requirement, and no user interaction; it also characterizes the condition as high complexity.
• The flaw is relevant only when an application uses Twig sandbox mode and reaches affected template evaluation. Whether an attacker can provide or influence the template must be assessed in the individual application.
• The available evidence does not establish in-the-wild exploitation or a public exploit. Public exploitation detail is therefore limited, and the absence of a recorded exploit status should not be treated as evidence that exploitation has not occurred.

Successful exploitation can disclose data returned by __toString(), including debug information, database entry IDs, usernames, or other application-specific values identified by the vendor. The technical outcome is loss of confidentiality; the supplied metadata does not indicate integrity or availability impact. Remote unauthenticated reachability is recorded, but actual exposure depends on a reachable sandbox template path and on what object data is exposed. Organisational consequences may include leakage of internal identifiers or user information and the need to review affected responses, but the record does not establish a breach or broader compromise.

• An attacker who reaches an affected template-evaluation path may read information exposed by an object's __toString() method, such as debug details, database entry IDs, or usernames.
• The evidence supports data and internal-information disclosure. The record does not establish a path to modify data, execute code, or disrupt service, so those outcomes should not be assumed.
• Exposure is most relevant to applications using Twig sandbox mode with objects whose string conversion returns sensitive information.
• Leakage of internal identifiers or user information may require review of related responses, templates, and returned data, but the record does not establish a specific breach or compromise.

1. Upgrade Twig 1.x deployments to 1.38.0 and Twig 2.x deployments to 2.7.0, following the vendor's branch-specific fixes.
2. On Debian stretch, install the twig package update 1.24.0-2+deb9u1.
3. Until patching is complete, avoid evaluating non-trusted templates with Twig sandbox mode where possible. Treat this as temporary risk reduction, not a replacement for the fixed package.
4. After updating, verify the deployed package and dependency lockfile, then retest sandbox policies and templates that render objects or pass objects through filters, functions, and concatenation.

1. Inventory the exact Twig versions in deployment, including dependency lockfiles and related operating-system packages.
2. Identify applications that enable Twig sandbox mode and the paths that evaluate non-trusted templates or templates influenced by requests, user data, or external sources.
3. Review templates and integration code for objects rendered or passed through operations that may trigger implicit string conversion, including filters, functions, and concatenation.
4. Inspect classes supplied to templates, especially their __toString() implementations, to determine whether they return debug information, database entry IDs, usernames, or other sensitive data.
5. As a precaution, monitor for unusual responses containing internal identifiers, usernames, or debug information. The absence of such evidence in logs or responses does not prove that the system is safe.