Handling Value Objects

Contributed by Mathias Arlaud in #63339

By default, JsonStreamer serializes an object by traversing its properties one by one. However, some objects are better represented as a single scalar value than as a nested JSON object. Think of a Money object encoded as "100 EUR" or a temperature represented as a number.

Symfony 8.1 introduces a generic mechanism for this called value objects. Implement the new ValueObjectTransformerInterface to define how an object maps to and from a scalar value:

// src/Transformer/MoneyValueObjectTransformer.php
namespace App\Transformer;

use App\ValueObject\Money;
use Symfony\Component\JsonStreamer\Transformer\ValueObjectTransformerInterface;
use Symfony\Component\TypeInfo\Type;
use Symfony\Component\TypeInfo\Type\BuiltinType;

/**
 * @implements ValueObjectTransformerInterface<Money, string>
 */
class MoneyValueObjectTransformer implements ValueObjectTransformerInterface
{
    public function transform(object $object, array $options = []): int|float|string|bool|null
    {
        return $object->amount.' '.$object->currency;
    }

    public function reverseTransform(int|float|string|bool|null $scalar, array $options = []): object
    {
        [$amount, $currency] = explode(' ', $scalar);

        return new Money((int) $amount, $currency);
    }

    public static function getStreamValueType(): BuiltinType
    {
        return Type::string();
    }

    public static function getValueObjectClassName(): string
    {
        return Money::class;
    }
}

Symfony auto-registers these transformers, and the generated code then calls the transformer instead of traversing the object's properties:

// write: "100 EUR"
$json = $jsonStreamWriter->write(new Money(100, 'EUR'), Type::object(Money::class));

// read: "100 EUR" -> Money(100, 'EUR')
$money = $jsonStreamReader->read('"100 EUR"', Type::object(Money::class));

Built-in DateInterval and DateTimeZone Value Objects

Contributed by Mathias Arlaud in #63742 and #63879

Building on the value object mechanism, Symfony 8.1 now handles DateInterval and DateTimeZone objects as value objects out of the box, following the same approach already used for DateTimeInterface.

DateInterval objects are serialized to ISO 8601 duration strings (e.g. P2Y6M1DT12H30M5S), and DateTimeZone objects use their name (e.g. "Europe/Paris" or "+02:00"). You can customize the duration format with the date_interval_format option:

use Symfony\Component\TypeInfo\Type;

$json = $jsonStreamWriter->write($task, Type::object(Task::class), [
    'date_interval_format' => 'P%yY%mM%dDT%hH%iM%sS',
]);

Configuring the DateTime Timezone

Contributed by Mathias Arlaud in #63735

When encoding or decoding DateTimeInterface objects, you can now convert the timezone by passing the date_time_timezone option as a string or a \DateTimeZone instance:

use Symfony\Component\TypeInfo\Type;

$json = $jsonStreamWriter->write($event, Type::object(Event::class), [
    'date_time_timezone' => 'Asia/Tokyo',
]);

$event = $jsonStreamReader->read($json, Type::object(Event::class), [
    'date_time_timezone' => new \DateTimeZone('America/Mexico_City'),
]);

Defining Default Options

Contributed by Mathias Arlaud in #62599

Repeating the same options on every write() and read() call is tedious. Symfony 8.1 lets you define default options for the entire application, so they are applied automatically to every operation:

# config/packages/framework.yaml
framework:
    json_streamer:
        default_options:
            # encode properties whose value is null
            include_null_properties: true

You can also define your own custom options here. Symfony passes them to your transformers, so you can read them inside transform() and reverseTransform():

# config/packages/framework.yaml
framework:
    json_streamer:
        default_options:
            my_custom_option: 'my_custom_value'

Custom JsonPath Functions

Contributed by Alexandre Daubois in #62823

The JsonPath component already supports the standard functions defined by RFC 9535 (length(), count(), match(), etc.). Symfony 8.1 lets you register your own functions and use them inside filter expressions.

Create an invokable class and apply the #[AsJsonPathFunction] attribute to it. Symfony registers the function automatically and makes it available in all JsonPath queries:

use Symfony\Component\JsonPath\Attribute\AsJsonPathFunction;

#[AsJsonPathFunction('upper')]
final class UppercaseFunction
{
    public function __invoke(mixed $value): ?string
    {
        return \is_string($value) ? strtoupper($value) : null;
    }
}

Inject the JsonPathCrawlerInterface to get a crawler pre-configured with all your custom functions, then use them in any expression:

$crawler = $crawlerFactory->crawl($json);

$result = $crawler->find('$.items[?upper(@.title) == "HELLO"]');

The number of arguments accepted by the function is inferred automatically from the __invoke() method signature. The optional returnType argument controls where the function can be used: a FunctionReturnType::Value function (the default) works in comparisons like the example above, while a FunctionReturnType::Logical function can be used as a standalone filter test such as $.items[?is_positive(@.value)].

Description

This is a residual bypass of CVE-2026-47732 / GHSA-pr2w-4gpj-cpq4 left after the initial fix for unguarded __toString() calls. It covers two related coercion points that were not caught by the original patch.

Traversable in the join and replace filters. SandboxExtension::ensureToStringAllowed() recurses into PHP arrays so that a Stringable object hidden inside an array argument cannot be string-coerced without consulting the security policy. The recursion stops at PHP arrays: a Traversable value passed at the same position is not materialised, so its contents are not policy-checked. CoreExtension::join() and CoreExtension::replace() later materialise such Traversable inputs through self::toArray() and feed them to implode() / strtr(), both of which implicitly call __toString() on contained Stringable objects. The bypass also reproduces when the container implements both Stringable and Traversable: the container's own __toString() is policy-checked, but the elements yielded by getIterator() are not, and the consuming filters still coerce them to string.

The in and not in operators. InBinary and NotInBinary compile to CoreExtension::inFilter(), which falls through to PHP's <=> operator when comparing a string with a Stringable object. PHP coerces the object to string via __toString() without the sandbox policy being consulted. Beyond the direct side effect, in can also be used as a content-leak oracle: each probe against an attacker-chosen needle leaks one bit of equality, and chained probes can reconstruct the string returned by __toString() even when every method is denied. The bypass reproduces with both array and Traversable haystacks, and on both operand sides.

A sandboxed template author who is allowed to call join / replace, or to use the in / not in operators, can therefore trigger a disallowed __toString() method on objects reachable from the render context, even when that method is not on SecurityPolicy::$allowedMethods. The bypass reproduces both under global sandbox mode and when sandboxing is enabled through SourcePolicyInterface.

Resolution

SandboxExtension::ensureToStringAllowed() now also recurses into Traversable operands when sandboxing is active for the current source: each value is materialised once and run through the same array-recursion path, so the policy is consulted before the filter implementation can coerce contained objects to strings. This applies to plain Traversable operands as well as to containers that implement both Stringable and Traversable: the container's own __toString() is still policy-checked, and the yielded elements are additionally checked. The materialisation is guarded by isSandboxed($source) so that non-sandboxed code paths do not pay the cost or change generator-exhaustion semantics.

InBinary and NotInBinary now implement Twig\Node\CoercesChildrenToStringInterface and declare both operands as string-coerced, so SandboxNodeVisitor wraps each operand in CheckToStringNode. The policy is consulted before CoreExtension::inFilter() reaches PHP's <=> operator, matching the existing protection on the other comparison binaries (Equal, Less, Greater, Spaceship, ...).

Credits

We would like to thank Vincent55 Yang and Fabien Potencier for reporting the issues and Fabien Potencier for providing the fix.

Description

The per-template filter, tag and function allow-list check is compiled into the checkSecurity() method of each Template subclass and was invoked once from the constructor, gated by SandboxExtension::isSandboxed($source). Template instances are then cached on the Environment in $loadedTemplates, so the verdict computed at construction time was sticky for the rest of the process.

Any later change of sandbox state on the same Environment left that cached verdict in place: toggling SandboxExtension::enableSandbox() / disableSandbox(), swapping the policy via setSecurityPolicy(), a SourcePolicyInterface decision flip, or simply having a parent, macro or included template pre-instantiated outside the sandbox before a sandboxed render reached it. In all of these cases, the filters, tags and functions used by the affected template kept running with the original (typically empty) check, bypassing the SecurityPolicy allow-list.

Method, property and __toString allow-lists are not affected: they are enforced at every call site at runtime through SandboxExtension::checkMethodAllowed(), checkPropertyAllowed() and ensureToStringAllowed(), which re-read the current state on every call.

Long-lived workers (FrankenPHP, RoadRunner, Symfony Messenger consumers, FPM with hot autoloading) that share a single Environment between sandboxed and non-sandboxed renders are the most exposed: a single non-sandboxed render of a shared layout pre-warms its Template instance, after which any later sandboxed render that extends, uses, includes or imports from that layout silently skips the filter/tag/function allow-list for the pre-warmed instance.

Resolution

The allow-list check is no longer run from the constructor. Template gains a public ensureSecurityChecked() method that calls the compiled checkSecurity() only when SandboxExtension::isSandboxed($source) returns true for the current source, and it is invoked at every entry point that can reach a Template instance whose security has not yet been verified against the current state: Template::yield(), Template::yieldBlock() (on the resolved block template, which covers extends, use, traits and parent blocks), Template::getParent() (which evaluates user code when the parent name is dynamic) and Template::getTemplateForMacro() (on the resolved macro template).

The explicit checkSecurity() calls previously emitted by IncludeNode and CoreExtension::include() are removed: the included template's own yield() now re-runs the check against the current sandbox state. The compiled checkSecurity() body is a cheap walk over compile-time-static arrays, so the per-render cost is negligible. Old cached compiled PHP files keep working unchanged: the constructor-time call they still contain is idempotent.

Credits

We would like to thank Fabien Potencier for reporting and fixing the issue.

Description

This is a residual bypass of CVE-2026-47732 / GHSA-pr2w-4gpj-cpq4 left after the initial fix for unguarded __toString() calls.

In 3.26.0 the sandbox visitor was extended to wrap every child node that its parent will string-coerce at runtime with CheckToStringNode, gated by the new CoercesChildrenToStringInterface. ArrayExpression did not implement the interface for its mapping keys: when a dynamic key expression resolves to a Stringable object, ArrayExpression::compile() emits a raw (string) cast (via StringCastUnary for ContextVariable keys, and no cast at all for richer key expressions). PHP then invokes __toString() directly, without ever calling SandboxExtension::ensureToStringAllowed().

A sandboxed template author can therefore trigger __toString() on any object reachable in the render context by using it as a dynamic mapping key, for example:

{% set arr = {(obj): "value"} %}

Direct output of the same object is correctly blocked, which makes this a clear policy enforcement gap. The reliable demonstrated impact is unauthorised disclosure of data returned by __toString().

Resolution

ArrayExpression now declares its dynamic mapping keys as string-coercion sites through CoercesChildrenToStringInterface, so the sandbox visitor wraps them with CheckToStringNode and the policy is consulted before PHP coerces the key to a string. The compiler also keeps an explicit (string) cast around the wrapped expression so PHP type errors on non-string keys are preserved.

As a side effect, any expression is now accepted as a dynamic mapping key (not only context variables); this is documented as a new feature on the 3.x branch.

Credits

We would like to thank El Kharoubi Iosif for reporting the issue and Fabien Potencier for providing the fix.

Description

The 3.26.0 source-policy hardening changed the signature of CoreExtension::checkArrow() to take a boolean $isSandboxed instead of an Environment, and added the same $isSandboxed argument to CoreExtension::arraySome() and CoreExtension::arrayEvery(). Compiled templates were updated to pass the per-source sandbox state computed at the call site.

The deprecated internal wrappers exposed in src/Resources/core.php for legacy third-party code (twig_check_arrow_in_sandbox(), twig_array_some(), twig_array_every()) were not updated:

• twig_array_some() and twig_array_every() call CoreExtension::arraySome() / arrayEvery() without forwarding the sandbox state. The underlying methods default $isSandboxed to false, so the callable-must-be-a-Closure restriction is silently bypassed in sandbox mode and a string callable such as 'strcmp' is accepted.
• twig_check_arrow_in_sandbox() passes the Environment object where CoreExtension::checkArrow() now expects a bool, which throws a TypeError on PHP 8+.

Compiled Twig templates are not affected: they call CoreExtension::* directly with the correct arguments. Applications are only impacted if they still call the deprecated twig_* helpers on top of a sandboxed Environment.

Resolution

The three wrappers now resolve the current sandbox state via twig_resolve_is_sandboxed() (the same helper compiled templates use), and forward it to the corresponding CoreExtension::* method. twig_check_arrow_in_sandbox() no longer triggers a TypeError, and twig_array_some() / twig_array_every() now enforce the same sandbox restriction as compiled templates.

Credits

We would like to thank El Kharoubi Iosif for reporting the issue and Fabien Potencier for providing the fix.

Description

This is a residual bypass of CVE-2026-46635 / GHSA-vcc8-phrv-43wj that only affects sandboxing enabled through SourcePolicyInterface (and not the regular global sandbox mode).

CoreExtension::column() receives the active sandbox state via the needs_is_sandboxed channel as a boolean $isSandboxed, but then routes the per-element property reads through SandboxExtension::checkPropertyAllowed() without forwarding the current Source. SandboxExtension::checkPropertyAllowed() re-evaluates isSandboxed($source) internally; with $source = null the SourcePolicyInterface-driven decision is lost, the method short-circuits to "not sandboxed", and the property allowlist is never consulted.

A template author whose sandbox is gated by a SourcePolicyInterface and who has column on their allowedFilters list can therefore read any public or magic property of any object reachable in the render context, regardless of SecurityPolicy::$allowedProperties. Direct attribute access to the same property is blocked, and the same payload is also blocked under global sandbox mode, which makes this a clear policy enforcement gap rather than a configuration issue.

Resolution

CoreExtension::column() no longer goes through the SandboxExtension wrapper for the property check. It calls the security policy directly: the per-source decision is already captured by the $isSandboxed boolean computed at the call site, so the property allowlist is enforced consistently for both global and source-policy sandboxing.

Credits

We would like to thank Vincent55 Yang for reporting the issue and Fabien Potencier for providing the fix.