CVE-2026-66295

Koder XML Saxy zapisuje cel i treść instrukcji przetwarzania w dokumencie wyjściowym dosłownie, bez sprawdzania poprawności i ucieczki. Koder buduje konstrukcję, łącząc oba pola pomiędzy <? i ?>, więc żadne pole nie jest sprawdzane pod kątem ograniczeń nałożonych na nie przez specyfikację XML.

Ponieważ ?> kończy instrukcję przetwarzania, wartość docelowa lub treść zawierająca tę sekwencję zamyka konstrukcję w pozycji wybranej przez atakującego. Wszystko, co osoba atakująca napisze po tym, jest emitowane jako zwykłe znaczniki na poziomie dokumentu, co umożliwia wstrzyknięcie dowolnych elementów, atrybutów i instrukcji dalszego przetwarzania do serializowanego dokumentu. Dołączanie pasującego <? utrzymuje terminator kodera w dobrej formie, więc wynik nadal jest analizowany, a zastrzyk jest cichy, a nie widoczne zniekształcenie. Cel nie jest dodatkowo ograniczony przez produkcję nazwy XML, co pozwala na wstrzyknięcie przed pozostałą częścią instrukcji przetwarzania.

Rezultatem jest wstrzyknięcie XML do serializowanego dokumentu: drzewo, o zakodowanie którego aplikacja prosi Saxy, i drzewo, które odczytuje dalszy parser, nie są już takie same. Dane znakowe, wartości atrybutów i komentarze są usuwane przez koder, więc instrukcje przetwarzania są jedyną konstrukcją, która przekazuje bajty użytkownika w nienaruszonym stanie. Ponieważ Saxy.XML.processing_instruction/2 jest udokumentowanym publicznym narzędziem do budowania, aplikacja dziedziczy tę lukę bez niewłaściwego korzystania z interfejsu API. Konsekwencje zależą od tego, co zużywa XML: sfałszowane rekordy w pliku danych lub eksporcie odczytywane przez inny system, wstrzyknięty arkusz stylów lub dyrektywy dotyczące renderowania lub aktywna treść, której dane wyjściowe są podawane do przeglądarki w formacie XML lub SVG.

Ten problem dotyczy Saxy: od 0.7.0 do 1.7.0.