Affected versions
Symfony Serializer versions >=5.4.41, <5.4.56, >=6.4.9, <6.4.50, >=7.0.9, <7.1.0, >=7.1.2, <7.4.23, >=8, <8.1.11 are affected by this security issue.
The issue has been fixed in Symfony Serializer 5.4.56, 6.4.50, 7.4.23, 8.1.11.
Description
ObjectNormalizer::isAllowedAttribute() treats any attribute name containing . (and, from 6.4, [) as writable, and setAttributeValue() hands the name straight to PropertyAccessor::setValue(), which parses it as a property path and traverses into the nested object.
A payload key such as customer.admin therefore writes to $order->customer->admin, bypassing the #[Ignore] metadata of the nested class. That metadata is only consulted when the nested object is denormalized in its own right, never when it is reached through a path. #[Groups] restrictions are not bypassed: the path is only accepted when no groups are passed in the context, and then groups restrict nothing.
No allowlist stands in the way. When the root class carries no #[Ignore] and no #[Groups], AbstractNormalizer::getAllowedAttributes() returns false and every key in the payload is let through:
1
{"customer": {"name": "Mallory"}, "qty": 1, "customer.admin": true}The first key denormalizes customer normally, honouring #[Ignore] on admin. The third key takes the path fast lane and sets admin anyway.
Applications that bind untrusted input to objects are affected, including controllers using #[MapRequestPayload] or #[MapQueryString], whose default normalizer is ObjectNormalizer. With OBJECT_TO_POPULATE, as used for partial updates, the traversal reaches an already hydrated entity graph and the modified field may be persisted.
Because PropertyAccessor resolves a path segment against public methods as well as properties, a segment matching a public method name invokes that method with the attacker's value.
The path support itself is deliberate: class metadata may declare an attribute whose name is a property path and expose it under a serialized_name. Only paths that no mapping ever declared are a problem.
Resolution
A property path is accepted only when the class metadata declares an attribute of that exact name. Declared paths keep working unchanged; a path arriving in the payload with no matching declaration is ignored.
On 6.4 and above the check is placed before the static writability cache is consulted. That cache is keyed on class, attribute and extraction context only, so caching a metadata-dependent answer would let one normalizer answer for another and could restore the bypass.
The patches for this issue are available here for branch 5.4 and here for branch 6.4 (and forward-ported to 7.4, 8.1 and 8.2).
Credits
We would like to thank Alexandre Daubois and The PHP Foundation for reporting the issue.