upb Any-recursion audit (Ruby / PHP / C# bindings)

Status: Complete. Six recursion-guard checks across three independent implementations (Ruby/PHP shared upb core, C#'s separate managed implementation), all falsified except the one already-public, already-patched Python CVE this audit was checking against. No new vulnerabilities were found.

Follow-up to confirmed Any-unwrapping recursion CVEs in protobuf's Python and JavaScript bindings (most recently CVE-2026-0994, a pure-Python bug in json_format.py's _ConvertAnyMessage, which recursed via methodcaller() instead of ConvertMessage() and silently skipped the depth counter).

Question: does the same bug class exist in the C upb core bundled into the Ruby and PHP native extensions?

Short answer: no. The JSON-decode path, the binary wire-decode path, and the independent managed C# implementation all enforce their recursion limits correctly under every case tested here, including a 200,000-level stress payload run under a 1MB stack. This is a falsified hypothesis with evidence, not a vulnerability — it's recorded here as a clean negative result, the same way you'd log a falsified hypothesis in any other research thread.

What's actually being tested

Protobuf's Ruby and PHP native extensions each vendor a single-file amalgamation of upb's C core (ruby-upb.c, php-upb.c) rather than linking a shared library. This audit builds that exact file as a standalone C target — no Ruby or PHP runtime involved — bootstraps a upb_DefPool with google.protobuf.Any / Struct / Value / ListValue descriptors, and drives the real decoder entry points (upb_JsonDecode, upb_Decode) directly with adversarial payloads, under ASan/UBSan.

Path	Guard	Default limit	Result
JSON decode, jsondec_any (Ruby)	d->depth, checked in jsondec_push	64	Falsified — clean error at 5000-level payload, byte offset matches ~64 levels exactly
Binary wire decode, upb_Decode (Ruby)	Decode_LimitDepth	100	Falsified — clean kUpb_DecodeStatus_MaxDepthExceeded at 60-level boundary payload and at 200,000-level stress payload, both under an 8MB stack and a 1MB stack (approximating a non-main Ruby thread)
PHP binding	same guard functions	same	Falsified by proof of identity, not a separate run — see below
JSON decode, JsonParser.MergeAny (C#, Google.Protobuf 3.36.1)	tokenizer.RecursionDepth, checked in Merge()	100	Falsified — confirmed at 200-level payload; MergeAny constructs a new JsonTokenizer via FromReplayedTokens per Any-unwrap, but depth accounting correctly propagates through it
Binary wire decode, CodedInputStream/Value.Parser (C#, Google.Protobuf 3.36.1)	recursionDepth/recursionLimit on the stream	64	Falsified — clean InvalidProtocolBufferException at 60-level boundary payload (same payload bytes as the Ruby wire test, reused directly)

No ASan or UBSan violation was observed in any run. No crash, no hang, no stack exhaustion.

Why PHP wasn't run separately

php-upb.c and ruby-upb.c differ by ~1,964 lines overall, but jsondec_any, jsondec_push, and the wire depth-limit constants are byte-identical between the two files (verify_php_identical.sh proves this, don't take it on faith — run it). Since the guard code itself is provably the same, the Ruby result transfers without needing a redundant PHP-specific harness.

What's still open

Four bindings tested (Ruby, PHP, C#, plus Python's already-public CVE), all falsified except the one that was already patched upstream. Remaining open threads, none of them this specific bug class:

• Other bug classes in the upb C core: extension registry confusion, mini_table parsing, the bundled utf8_range.c validation.
• The C# wire-decode test (dotnet run -- wire <payload>) isn't wired into CI yet — only the JSON-mode C# test is automated.

Reproducing this

./fetch_source.sh          # pins & clones protobuf @ ead3f0029facc43da13588132e9091bf9bd7a26f
./build.sh                 # compiles both harnesses w/ ASan+UBSan against the fetched source
./run_tests.sh              # generates payloads, runs the full matrix, prints results
./verify_php_identical.sh   # confirms the PHP claim above instead of asserting it

Requires: gcc, protoc (apt-get install protobuf-compiler), python3, git. Built and verified against gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0 and libprotoc 3.21.12 — different versions may behave differently; if your results don't match the table above, that's data, not a bug in your setup. Find out why before assuming it's a tooling mismatch.

Provenance note

third_party/ (fetched by fetch_source.sh) contains Google's Apache-2.0-licensed protobuf source, pinned to the commit above. It is never committed to this repo — fetch_source.sh is the reproducibility anchor instead of vendoring someone else's source tree into this one.