Wysoki Odebrany

CVE-2026-85515

opublikowano: 03.10.2026, 11:17

modyfikacja: 03.10.2026, 11:17

Ocena CVSS

8.2

Wysoki · v4.0

Oficjalne źródła

wektor: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W Bouncy Castle dla języka Java przed wersją 1.86 obcięta wiadomość zaszyfrowana w formacie OpenPGP została zaakceptowana bez zgłaszania błędów, a w ścieżce SEIPD w wersji 1 nie przeprowadzono żadnego sprawdzania integralności. RFC 9580 sek. Wersja 13.7 pozwala implementacji na uwolnienie jawnego tekstu w pełni uwierzytelnionych fragmentów podczas przesyłania strumieniowego, ale wymaga wskazania wyraźnego błędu natychmiast po wykryciu obcięcia i zgłoszenia podejrzanej integralności po wykryciu plastycznego tekstu zaszyfrowanego. Obcięcie zostało wykryte, a następnie odrzucone: gdy wiadomość zostanie obcięta, ale pole długości otaczającego pakietu pozostanie niezmienione, BCPGInputStream.PartialInputStream zgłasza wyjątek EOFException dla brakującego tekstu zaszyfrowanego, a BCPGInputStream.nextPacketTag() zgłasza wyjątek EOFException jako czysty koniec wiadomości, więc strumień pakietu powyżej zatrzymał się, jak gdyby nie pozostały żadne pakiety. Na ścieżce AEAD (pakiet AEAD SEIPD w wersji 2 i wersji 5), gdy dosłowny pakiet danych zakończył się na granicy fragmentu AEAD, a konsument czytał w odstępach mniejszych niż jeden fragment, wyczekiwanie pakietu po literale wyzwoliło odczyt obciętego fragmentu, więc BcAEADUtil i JceAEADUtil nigdy nie osiągnęły końcowego znacznika komunikatu o sekundach. 5.13.2, który uwierzytelnia całkowitą długość tekstu jawnego; osoba wywołująca otrzymała zwykły tekst w pełni uwierzytelnionych fragmentów, każdy pakiet następujący po literale został po cichu odrzucony i nie został zgłoszony żaden wyjątek, więc podpisana i zaszyfrowana wiadomość została odczytana jako dobrze uformowana, niepodpisana. Każdy bajt uwolniony na tej ścieżce pozostał indywidualnie uwierzytelniony, co oznacza raczej brakujący błąd obcięcia niż fałszerstwo i stanowi pozostałość CVE-2026-12817, który zamknął ten sam wynik dla atakującego, który korygował zewnętrzną długość pakietu. Na ścieżce SEIPD w wersji 1 konsekwencje były poważniejsze: IntegrityProtectedInputStream weryfikuje kod wykrywania modyfikacji z metody Close() i osiąga funkcję Close() tylko poprzez zamknięcie się, gdy jego odczytanie zwróciło wartość -1, czego obcięta wiadomość nigdy nie generuje, zatem funkcja PGPEncryptedData.verify() nigdy nie została uruchomiona, a odbiorca otrzymał zwykły tekst odszyfrowany za pomocą CFB, na którym nie przeprowadzono żadnego sprawdzania integralności. Zmierzone w wiadomości obciętej do tego kształtu, 136 odrębnych jednobajtowych modyfikacji otrzymanego tekstu zaszyfrowanego zaakceptowało zmieniony tekst jawny bez żadnych wyjątków. Osiągalność jest właściwością komunikatu, a nie danych wejściowych dostarczonych przez atakującego: kształt AEAD utrzymywany jest dla 3 ze 131 kolejnych zmierzonych długości ładunku, a kształt SEIPD w wersji 1 dla jednej długości ładunku na szesnaście, przy przesunięciu obcięcia, które nie zmienia się wraz z długością ładunku. Nie ma to wpływu na niskopoziomowy interfejs API, obiekt wywołujący wywołujący PGPEncryptedData.verify() bezpośrednio otrzymuje sprawdzenie, niezależnie od tego, podobnie jak konsumenci czytający w przyrostach całego fragmentu AEAD lub więcej. Strumienie deszyfrujące AEAD zgłaszają teraz taki wyjątek EOFException jako zwykły wyjątek IOException, którego funkcja nextPacketTag() nie prasuje; OpenPGPMessageInputStream.close() zamyka teraz sam strumień chroniony integralnością swojej warstwy, zamiast polegać na tym, że strumień zobaczył koniec swoich danych; i IntegrityProtectedInputStream.close() stała się idempotentna, zgodnie z wymaganiami Java.io.Closeable, od czego to zależy, ponieważ strumień jest rzeczywiście zamykany dwukrotnie na zwykłej ścieżce, a PGPEncryptedData.verify() zużywa znajdujący się za nim stan podsumowania i nie można go uruchomić po raz drugi. Ten problem dotyczy również Bouncy Castle dla Java LTS przed wersją 2.73.13, tylko na trasie AEAD, ponieważ ta edycja nie dostarcza wysokiego poziomu interfejsu API OpenPGP, przez który przebiega trasa SEIPDv1. Dotyczy to również Bouncy Castle dla Java FIPS (BC-FJA) przed bcpg-fips 1.0.14 (seria 1.0.X), 2.0.14.1 (seria 2.0.X) i 2.1.14 (seria 2.1.X), tylko na trasie AEAD, ponieważ te edycje nie dostarczają wysokiego poziomu API OpenPGP.

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.

>_ Słabości (CWE)

CWE-345 CWE-354

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve