Hi, A correction to my previous message regarding CVE-2026-118693.
There I listed "_create_image_from_xml reading the filename attribute" as making the shipped versions affected. On closer inspection that is not accurate: the attribute is read, but in 0.99.48 and 1.2.0 it is never used to open a file, so the arbitrary read described in the CVE is not reachable there. - 0.99.48 has no multifile support; _create_image_from_xml takes the embedded-file bytes only from base64 in the XML. The filename is kept for display and as the save-dialog default, but never opens a file. - 1.2.0 takes the bytes from base64 (single-file) or from the multifile store keyed by the sha256sum attribute (CtStorageMultiFile::read_blob matches on sha256sum), never from a path built from "filename". The read fixed by 61fca359a431 lives in newer code: CtImageEmbFile::_checkNonEmptyRawBlob reads multifile_dir/_fileName when the in-document blob is empty. That function is not present in 0.99.48 or 1.2.0. So I would suggest CVE-2026-118693 is not-affected for bookworm 0.99.48 and trixie/sid/forky 1.2.0. The only related weakness I can find in these versions is a possible traversal in the temporary filename when a user explicitly opens an embedded file (CtActions::embfile_open reuses the stored name unsanitised); upstream's sanitize_filename also covers that, and I can send a small hardening backport if you consider it in scope. CVE-2026-118692 and the backports attached to my previous message are unaffected by this correction. Regards, Sumit
