Protobuf FieldMask is non-recursive structure at parse time (no depth limit to enforce) but the FieldMaskTree handling of it is unconstrained recursive algorithm

[VenkatKwest]

Summary:
The Protobuf pure-Python implementation is vulnerable to a severe, unbounded recursion bypass within the FieldMask utility module. An attacker can supply a single FieldMask path consisting of thousands of segments (e.g., "a.a.a.a...") to bypass all standard recursion guards. When a server processes this payload using standard business logic APIs (like Union, Intersect, or CanonicalFormFromMask), the library attempts to build a massive internal tree without any depth checks, triggering a guaranteed RecursionError. This causes a fatal crash and a Remote Denial of Service (DoS) in any application parsing untrusted updates.this vulnerability is completely unbounded. A malicious path can safely glide past standard parser depth limits because the binary and JSON parsers view it as a flat string.

Affected Component: protocolbuffers/protobuf (Python runtime - google/protobuf/internal/field_mask.py)
Version: Current main (up to and including 5.29.0)
Environment Tested:

• Python: 3.10.12 (Pure Python Backend: PROTOBUF_PYTHON_IMPLEMENTATION=python)
• protoc: Official PyPI release 5.29.0
• OS: Ubuntu 22.04 (WSL2)

---

Technical Description

While standard Protobuf parsing checks current_depth against a limit (usually 100) when encountering nested objects, FieldMask introduces a critical parsing gap between the "Wire State" and the "Application State".

1. The Parsing Blind Spot

On the wire (JSON or Binary), a FieldMask is defined as a repeatable string type. When an attacker sends a message containing:
paths: ["a.a.a.a.a.a...."]
The parser decodes this at Depth 1. The standard security limit of 100 is completely blind to the internal structure of the string, allowing an attacker to pack an arbitrarily deep logic bomb into a tiny (e.g., 2KB) payload.

2. The Missing Guard in FieldMask Utilities

In the official library file field_mask.py, the helper class _FieldMaskTree is responsible for converting these flat validation strings into usable mask structures.

Specifically, the method _AddFieldPaths recursively walks the constructed _FieldMaskTree without tracking recursion depth or checking against sys.getrecursionlimit():

# google/protobuf/internal/field_mask.py: 302
def _AddFieldPaths(node, prefix, field_mask):
  """Adds the field paths descended from node to field_mask."""
  if not node and prefix:
    field_mask.paths.append(prefix)
    return
  for name in sorted(node):
    if prefix:
      child_path = prefix + '.' + name
    else:
      child_path = name
    # VULNERABLE: Direct recursion without depth guard
    _AddFieldPaths(node[name], child_path, field_mask)

Because there is no depth threshold, an attacker can specify a 2,000-segment string, forcing _AddFieldPaths to recurse 2,000 times. This instantly exhausts Python's default recursion limit (1000) and terminates the worker process.

---

Attack Scenario

FieldMask is heavily utilized in gRPC and REST APIs that conform to Google's AIP-134 standard for Update operations.

1. Remote DoS via Mask Validation: A targeted service allows users to update their profile configurations. To enforce security, the server filters the user's requested update_mask against an internal allowed_fields_mask by calculating their mathematical intersection.
2. The server receives the attacker's payload (a 1,500-segment string). The payload parses perfectly.
3. The developer's backend logic allocates an empty mask and executes the standard result.Intersect(user_mask, allowed_mask) call.
4. The Protobuf library parses the malicious string into a tree, intersects it, and recursively collapses it via _AddFieldPaths.
5. The Python worker process crashes with a RecursionError, rendering the API endpoint unavailable.

---

Reproduction Steps

Environment Setup (WSL/Linux)

To prove this bypass exists in standard production deployments without custom modifications, we can use a pristine virtual environment installing the latest public release.

# Setup pristine venv to ensure pure-python backend
python3 -m venv test_env
source test_env/bin/activate
pip install protobuf==5.29.0
export PROTOBUF_PYTHON_IMPLEMENTATION=python

PoC: Real-World FieldMask Bypass

Create final_poc.py:

import os
from google.protobuf import field_mask_pb2
from google.protobuf.internal import field_mask

def test_union():
    print("--- Real-World FieldMask Unbounded Recursion PoC ---")
    
    # 1. Create a malicous mask that an attacker could provide via an API request.
    # Note: Parses beautifully because it's just a flat string!
    malicious_path = ".".join(["a"] * 1500)
    mask = field_mask_pb2.FieldMask(paths=[malicious_path])
    out_mask = field_mask_pb2.FieldMask()

    print(f"[*] Attacker payload parsed! Path has {len(malicious_path)} segments.")
    print("[*] Server calls official public API: FieldMask.Union()...")
    
    try:
        # 2. Trigger standard server-side business logic
        mask.Union(mask, out_mask)
        print("[-] FAILED: Application survived (Recursion Limit ignored?)")
    except RecursionError as e:
        print("\n[+] VULNERABILITY CONFIRMED: Real-world crash via RecursionError!")
        raise e

if __name__ == '__main__':
    test_union()

Run the script:

python3 final_poc.py

---

Stack Trace

When executing the real-world PoC on the official Protobuf 5.29.0 release, the RecursionError is triggered precisely at the unguarded _AddFieldPaths transition:

Traceback (most recent call last):
  File "/tmp/test_env/lib/python3.10/site-packages/google/protobuf/internal/field_mask.py", line 185, in _AddFieldPaths
    for name, child in sorted(node.children.items()):
RecursionError: maximum recursion depth exceeded while calling a Python object

---

Suggested Remediation

Because FieldMask path depth scales maliciously without increasing the overall parsed object depth, field_mask.py requires its own logic guard to prevent internal DoS.

1. Iterative Tree Walking: Rewrite _AddFieldPaths, IntersectPath, and _MergeMessage to utilize an iterative stack approach rather than direct function recursion.
2. Explicit Path Depth Limiter: In _FieldMaskTree.AddPath(self, path), implement an artificial depth ceiling limit (e.g., maximum 100 dot-separated segments) before admitting the path into the tree. Since dot-separated paths effectively constitute message nesting, they should respect the same standard nesting limit (100) strictly enforced globally by the parser.

[esrauchg]

Thanks for the interesting report!

This is a bit of an oddball case, since any recursive situation will only occur at some deferred point of use, as there's no input that would have a depth problem in just a parse > serialize round trip here.

We generally don't intend to enforce depth limits against anything constructed purely in-memory (as not attacker-controlled); it's a bit contrived but if someone did want to create a depth 150 field mask and use it in memory thats up to them to figure out if its ok or not, as not related to handling of adversarial-input. The second option proposed in the bottom of the original report would necessarily enforce a limit against those use cases, which in this scenario would maybe be fine (because its incredibly fringe for someone to want such a deep fieldmask in reality) but outside of our normal ethos.

I was going to say we could try to have JSON parse-fail on fieldmasks that are too deep (just too many '.' characters), but we actually cannot because WKT are fundamentally not considered 'special' in binary wire format (they're just simple non-privledged messages), so in binary wire format we could not have it parse-fail on field masks that are arbitrary number of path components as basically a first class semantic of "WKT are not special in wire format" (e.g. we also never reject Durations or Timestamps or whatever that are 'illegally shaped' in binary wire format, we only do in JSON).

I think we really do just need _FieldMaskTree to become iterative here if feasible.

[VenkatKwest]

Hi @esrauchg

Thank you for the quick turnaround and for implementing the iterative fix in PR #26535. It definitely makes the library more robust.

Regarding the security classification: while I understand the 'in-memory' perspective, in many production gRPC and REST environments (following AIP-134), the FieldMask string is directly provided by the client. Since this allows a remote, unauthenticated user to bypass the standard 100-depth limit and trigger a RecursionError crash during processing, it effectively functions as a Remote Denial of Service (DoS).

Does the team plan to issue a GitHub Security Advisory (GHSA) or a CVE for this? Without an official advisory, security scanners like Snyk, Dependabot, and Trivy will not be able to alert downstream users. This leaves many systems unknowingly vulnerable to this crash until they manually happen to upgrade. Providing a CVE would ensure the community is protected and properly notified.

[esrauchg]

the FieldMask string is directly provided by the client

Yes, sorry I wasn't clear in my wording. The 'in-memory' discussion above was mostly about how this is an interestingly exotic situation: our policy is we enforce limits at parse time, and do not enforce depth limits on subsequent operations.

But then the gotcha is that:

1. FieldMask is not a recursive data structure at parse time (its a flat list of path string components)
2. But there is a recursive algorithm over that non-recursive-data-structure.

Which makes a very odd situation that our normal policy stance wouldn't prevent the uncontrolled recursion on attacker controlled inputs. There's nothing to enforce at parse time (a length=10,000 FieldMask is perfectly legal in binary wire format and must not parse fail), and policy-wise we intentionally don't enforce recursive limits on in-memory operations that can be done after a parse (but, a length=10,000 fieldmask which is legal at parse time will be a problem when handled recursively).

The original text issue proposed two possible solutions; option 2 would put a depth limit on the in-memory operation. As the identified concern is a real bug we do want to close, if this option was the only way to fix we would do it, but it would be an exceptional situation to do something we normally would not do.

The proposed option 1 is the PR that I sent and seems to 'cut the knot' here without having to do anything we 'normally would not do'.

Does the team plan to issue a GitHub Security Advisory (GHSA) or a CVE for this?

Whether this specific issue warrants declaring a CVE is under discussion internally and we should be able to report back in about a week, thanks for bearing with us.