protocolbuffers/protobuf

What version of protobuf and what language are you using? Version: v36.1 Language: C++, through the CMake protobuf_generate() function What supported operating system version are you using (e.g. Linux, Windows) ? Linux (Arch Linux, x86_64) What supported runtime / compiler version are you using (e.g. python version, gcc version) GCC 16.2.1, CMake 4.4.3, Ninja 1.13.2 What did you do? put the below CMakeLists.txt in an empty directory. It writes a .proto into the build tree and passes that directory to protoc with --proto_path in PROTOC_OPTIONS: cmake_minimum_required(VERSION 3.16) project(repro CXX) find_package(protobuf CONFIG REQUIRED) set(gen_dir ${CMAKE_CURRENT_BINARY_DIR}/gen) file(WRITE ${gen_dir}/foo.proto "syntax = \"proto3\";\nmessage Foo { int32 x = 1; }\n") protobuf_generate(OUT_VAR srcs PROTOS ${gen_dir}/foo.proto PROTOC_OPTIONS --proto_path=${gen_dir}) add_custom_target(gen ALL DEPENDS ${srcs}) Configure with the build dir outside the source dir: cmake -S . -B ../

The proto3 JSON mapping encodes 64-bit integers, and optionally other numeric types, as JSON strings. When that string contains non-ASCII decimal digits, the three first-party implementations do not agree: Python and Java accept them, C++ rejects them. The same JSON document is therefore a valid message on two implementations and a parse error on the third. Repro probe.proto: syntax = "proto3"; package probe; message P { string s = 1; int32 i32 = 3; int64 i64 = 4; uint32 u32 = 5; double d = 6; } Python (protobuf runtime 7.36.2): from google.protobuf import json_format import probe_pb2 as M json_format.Parse('{"i64":"123"}', M.P()).i64 # 123 <- ASCII control json_format.Parse('{"i64":"١٢٣"}', M.P()).i64 # 123 <- Arabic-Indic U+0661-0663 json_format.Parse('{"i64":"1٢2"}', M.P()).i64 # 122 <- mixed ASCII + Arabic-Indic json_format.Parse('{"i64":"१२३"}', M.P()).i64 # 123 <- Devanagari json_format.Parse('{"i64":"abc"}', M.P()) # ParseErr

A vulnerability has been identified in the Protocol Buffers C++ library, specifically within the google::protobuf::MessageLite::ParseFromArray method. This issue arises from improper handling of the size parameter, leading to an integer signedness error when a negative value is provided. Vulnerability Details Type: Integer Signedness / Integer Overflow Component: google::protobuf::MessageLite File: protobuf/src/google/protobuf/message_lite.cc Method: ParseFromArray(const void* data, int size) Root Cause Analysis The ParseFromArray implementation is as follows: bool MessageLite::ParseFromArray(const void* data, int size) { return ParseFrom(as_string_view(data, size)); } The as_string_view helper (in the same file) performs a direct cast: inline absl::string_view as_string_view(const void* data, int size) { return absl::string_view(static_cast<const char*>(data), size); } If a negative int size is passed (e.g., -1), it is cast to a size_t by the absl::string_view constructor. On a 64-bit

What version of protobuf and what language are you using? Version: 35.0-rc2 (from BCR) Language: C++ What supported operating system version are you using (e.g. Linux, Windows) ? Windows 11 What supported runtime / compiler version are you using (e.g. python version, gcc version) MSVC What did you do? Attempt to build a protobuf target dependency on Windows 11. Steps to reproduce the behavior: On a Windows 11 fresh install, no WSL, no bash.exe Use Bazel and write a Protobuf target. In my specific case I installed opentelemetry-proto and tried to build a target which has dependency on metrics_proto here: https://github.com/bazelbuild/bazel-central-registry/blob/main/modules/opentelemetry-proto/1.8.0/overlay/BUILD.bazel Observe build failure What did you expect to see Successful build of a cc_proto_library() target What did you see instead? ERROR: C:/users/stepa/_bazel_stepa/hr2rqvqb/external/protobuf+/bazel/private/oss/toolchains/prebuilt/BUILD.bazel:25:20: ProtocAuthenticityCheck ext

IMPORTANT NOTE: SUBMITTED THIS ISSUE TO THE GOOGLE VRP TEAM FEW DAYS BACK. TEAM ACCEPT IT TO SUBMIT IT AS PUBLIC GITHUB ISSUE. Summary: The Protobuf pure-Python implementation is vulnerable to a recursion depth limit bypass in the MessageSet decoding path and a complete lack of recursion guards in the TextFormat parser. These issues allow an attacker to trigger a stack overflow (RecursionError) leading to a Denial of Service (DoS) in applications parsing untrusted data. Crucially, the MessageSet issue is a direct bypass of the fix implemented for GHSA-8qvm-5x2c-j2w7. Affected Component: protocolbuffers/protobuf (Python runtime) Version: Current main (Commit: 18da8e12d) Environment Tested: Python: 3.10.12 protoc: 3.12.4 (libprotoc) OS: Ubuntu 22.04 (WSL2) Technical Description While investigating the recent fix for GHSA-8qvm-5x2c-j2w7 (Recursion DoS in Python), I identified two significant regressions/oversights in how recursion depth is tracked. 1. MessageSet Depth Reset Bypass (Off