Unfortunately a CVE from a decade ago and the 2.x lineage are both sufficiently ancient history that we realistically don't have a lot of information on hand for this topic.
Just from the linked github advisory page, it does appear to me that what happened is that this was a C++Proto issue and likely the only patches were in C++, but all languages including Java and Go are listed on that CVE. There's two possible reasons that I can imagine that having happened: - Protobuf only had one unified numbering scheme (3.4.0 for all languages, unlike today where the numbering scheme is that each language is released as X.4.0 where X is a separate choice for each language and the 4.0 portion is the cross-version numbering). The CVE was simply declared on all "protobuf 3.4.0" and that was backed out to include things that it really didn't apply to, including Java and Go. - It may also have deliberately happened due to Protoc itself is implemented using C++Proto, which means ~all things using protoc technically do contain the vulnerable C++Proto code. However, supply chain attacks on protoc are not considered to be part of our threat model these days, so if we declared a CVE on C++Proto today we would not consider that to be a topic for JavaProto, though I'm unsure if that was the case a decade ago or not. On Thu, Jul 3, 2025 at 4:21 AM 'Somak Dutta' via Protocol Buffers < [email protected]> wrote: > Hi, > > I am writing to ask about vulnerability reported GHSA-jwvw-v7c5-m82h > <https://github.com/advisories/GHSA-jwvw-v7c5-m82h> for protobuf-java > <https://mvnrepository.com/artifact/com.google.protobuf/protobuf-java> which > specifically talks about "*protobuf allows remote authenticated attackers > to cause a heap-based buffer overflow.*" > > Specifically to ask about earlier versions < 3.4.0. > Take for example a version 2.5.0, based on all the code i see for > CodedInputStream > <https://github.com/protocolbuffers/protobuf/blob/v2.5.0/java/src/main/java/com/google/protobuf/CodedInputStream.java> > - methods such as readRawBytes/refillBuffer, which are performing either > copy to/from or resizing , are all pretty safe from integer overflows. > - there is also present a slow path, where we read buffer in chunks to > potentially prevent out of memory issues. > > First Question: > However i am not seeing any evidence where the package can be vulnerable > to a buffer overflows issues > Additionally given java is memory safe language i am failing to see how > java ecosystem is susceptible to the afore mentioned vulnerability. > > Second Question: > There is a question related / or along the same veins here > https://github.com/protocolbuffers/protobuf/issues/760?reload=1#issuecomment-847162817 > . The potential fix also suggests issue might be present only in c/c++ > ecosystems. > > > Any clarifications from the community would be appreciated. > Thank you > > > > > *Confidentiality Notice: This email and any attachments are confidential > and intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error, please notify the > sender immediately and delete it from your system. Unauthorized use, > disclosure, or copying of this email or its contents is strictly > prohibited.* > > -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/protobuf/b1dd5d8b-f50e-4545-b5d5-98920fc9bea2n%40googlegroups.com > <https://groups.google.com/d/msgid/protobuf/b1dd5d8b-f50e-4545-b5d5-98920fc9bea2n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/protobuf/CAKRmVH-pA8oxvux%3DSF2i1%2BGdtRFF6SpaRAyFyUqrYJ%2Bya3-RqA%40mail.gmail.com.
