CVE-2026-85515
Beschrijving NL
In Bouncy Castle voor Java vóór 1.86 werd een afgekapt OpenPGP gecodeerd bericht geaccepteerd zonder dat er een fout werd gemeld, en op het SEIPD-versie 1-pad zonder dat er een integriteitscontrole werd uitgevoerd. RFC 9580 sec. 13.7 staat een implementatie toe om de cleartext van de volledig geverifieerde brokken vrij te geven tijdens het streamen, maar vereist dat het een duidelijke fout aangeeft zodra de afknapping wordt gedetecteerd, en om verdachte integriteit te melden wanneer het kneedbare cijfertekst ontdekt. De afkorting werd gedetecteerd en vervolgens weggegooid: wanneer een bericht wordt afgekapt maar het lengteveld van het omsluitende pakket ongewijzigd blijft, verhoogt BCPGInputStream.PartialInputStream een EOFException voor de ontbrekende cijfertekst, en BCPGInputStream.nextPacketTag () rapporteert een EOFException als een schoon einde van het bericht, zodat de pakketstroom erboven stopte alsof er geen pakketten meer over waren. Op het AEAD-pad (SEIPD-versie 2 en het AEAD-pakket van versie 5), toen het letterlijke gegevenspakket eindigde op een AEAD-chunkgrens en de consument in stappen kleiner dan één chunk las, activeerde de look-ahead voor het pakket na het letterlijke de afgeknotte chunklezing, dus BcAEADUtil en JceAEADUtil bereikten nooit de achterliggende berichttag van sec. 5.13.2 die de totale lengte van de platte tekst authenticeert; de beller ontving de platte tekst van de volledig geverifieerde brokken, elk pakket na de letterlijke tekst werd stilletjes verwijderd en er werd geen uitzondering gemaakt, dus een ondertekend en gecodeerd bericht werd teruggelezen als een goedgevormd ongetekend bericht. Elke byte die op dat pad werd vrijgegeven, bleef individueel geverifieerd, waardoor dit een ontbrekende afkapfout is in plaats van een vervalsing, en het is een residu van CVE-2026-12817, dat dezelfde uitkomst heeft gesloten voor een aanvaller die de buitenste pakketlengte corrigeert. Op het SEIPD-versie 1-pad was het gevolg ernstiger: IntegrityProtectedInputStream verifieert de modificatiedetectiecode van close() en bereikte close() alleen door zichzelf te sluiten wanneer een read ervan -1 retourneerde, wat een afgekapt bericht nooit produceert, dus PGPEncryptedData.verify () liep nooit en de ontvanger kreeg CFB-versleutelde platte tekst overhandigd waarop geen integriteitscontrole van welke aard dan ook was uitgevoerd. Gemeten op een bericht afgekapt in die vorm, 136 verschillende single-byte modificaties van de geproduceerde ciphertext geaccepteerde, gewijzigde platte tekst zonder uitzondering verhoogd. Bereikbaarheid is een eigenschap van het bericht in plaats van van door de aanvaller geleverde invoer: de AEAD-vorm werd gedurende 3 van de 131 opeenvolgende gemeten payloadlengtes aangehouden, en de SEIPD-versie 1-vorm voor één payloadlengte in zestien, bij een afkappingsverschuiving die niet met de payloadlengte meebewoog. The low-level API is unaffected, a caller that invokes PGPEncryptedData.verify() directly getting the check regardless, as are consumers reading in increments of a whole AEAD chunk or more. De AEAD-decoderingsstromen gooien nu zo 'n EOFException terug als een gewone IOException, die nextPacketTag () niet witwast; OpenPGPMessageInputStream.close () sluit nu zelf de door integriteit beschermde stroom van zijn laag af in plaats van erop te vertrouwen dat die stroom het einde van zijn gegevens heeft gezien; en IntegrityProtectedInputStream.close () werd idempot gemaakt, zoals java.io.Closeable vereist, wat afhankelijk is van, aangezien de stroom echt twee keer wordt gesloten op het gewone pad en PGPEncrypt edData.verify() verbruikt de digeststatus erachter en kan niet een tweede keer worden uitgevoerd. Dit probleem heeft ook invloed op Bouncy Castle voor Java LTS vóór 2.73.13, alleen op de AEAD-route, omdat die editie niet de OpenPGP API op hoog niveau verzendt waar de SEIPDv1-route doorheen loopt. Het heeft ook invloed op Bouncy Castle voor Java FIPS (BC-FJA) vóór bcpg-fips 1.0.14 (1.0.X-SERIE), 2.0.14.1 (2.0.x-serie) en 2.1.14 (2.1.x-serie), alleen op de AEAD-route, omdat die edities de OpenPGP API op hoog niveau niet verzenden.
Origineel (Engels) tonen
In Bouncy Castle for Java before 1.86, a truncated OpenPGP encrypted message was accepted with no error reported, and on the SEIPD version 1 path with no integrity check performed at all. RFC 9580 sec. 13.7 permits an implementation to release the cleartext of the fully authenticated chunks when streaming but requires it to indicate a clear error as soon as the truncation is detected, and to report suspect integrity when it discovers malleable ciphertext. The truncation was detected and then discarded: when a message is truncated but the length field of the enclosing packet is left unchanged, BCPGInputStream.PartialInputStream raises an EOFException for the missing ciphertext, and BCPGInputStream.nextPacketTag() reports an EOFException as a clean end of message, so the packet stream above it stopped as though no packets remained. On the AEAD path (SEIPD version 2 and the version 5 AEAD packet), when the literal data packet ended on an AEAD chunk boundary and the consumer read in increments smaller than one chunk, the look-ahead for the packet after the literal triggered the truncated chunk read, so BcAEADUtil and JceAEADUtil never reached the trailing message tag of sec. 5.13.2 that authenticates the total plaintext length; the caller received the plaintext of the fully authenticated chunks, every packet following the literal was silently dropped, and no exception was raised, so a signed and encrypted message read back as a well-formed unsigned one. Every byte released on that path remained individually authenticated, making this a missing truncation error rather than a forgery, and it is a residual of CVE-2026-12817, which closed the same outcome for an attacker who corrects the outer packet length. On the SEIPD version 1 path the consequence was more serious: IntegrityProtectedInputStream verifies the modification detection code from close(), and reached close() only by closing itself when a read of it returned -1, which a truncated message never produces, so PGPEncryptedData.verify() never ran and the recipient was handed CFB-decrypted plaintext on which no integrity check of any kind had been performed. Measured on a message truncated into that shape, 136 distinct single-byte modifications of the ciphertext produced accepted, altered plaintext with no exception raised. Reachability is a property of the message rather than of attacker-supplied input: the AEAD shape held for 3 of 131 consecutive payload lengths measured, and the SEIPD version 1 shape for one payload length in sixteen, at a truncation offset that did not move with the payload length. The low-level API is unaffected, a caller that invokes PGPEncryptedData.verify() directly getting the check regardless, as are consumers reading in increments of a whole AEAD chunk or more. The AEAD decryption streams now re-throw such an EOFException as a plain IOException, which nextPacketTag() does not launder; OpenPGPMessageInputStream.close() now closes its layer's integrity-protected stream itself rather than relying on that stream having seen the end of its data; and IntegrityProtectedInputStream.close() was made idempotent, as java.io.Closeable requires, which that depends on, since the stream is genuinely closed twice on the ordinary path and PGPEncryptedData.verify() consumes the digest state behind it and cannot be run a second time. This issue also affects Bouncy Castle for Java LTS before 2.73.13, on the AEAD route only, as that edition does not ship the high-level OpenPGP API the SEIPDv1 route runs through. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpg-fips 1.0.14 (1.0.X series), 2.0.14.1 (2.0.X series) and 2.1.14 (2.1.X series), on the AEAD route only, as those editions do not ship the high-level OpenPGP API.