Embedded images the engine did not read
The document carries an embedded image large enough to hold readable text that this engine did not read.
How the text is hidden
An instruction can be painted into a bitmap and dropped into the document as an ordinary picture. The document's own bytes are XML and say nothing about what the picture contains, and there is no render step for Office formats — PDFium, which performs the render pass, cannot open a DOCX. So the pixels are opaque to everything that reads markup.
Why a model still reads it
Nothing on the byte side reads it, which is the whole content of this finding. A model handed the file's pixels, or a pipeline that OCRs what it receives, sees the words; the structural pass does not, so it says so rather than certifying over the image.
What we do about it
Every zip entry is inflated once and its format sniffed from magic bytes — PNG, JPEG, GIF, BMP — never from the file extension, because an OOXML part's type is resolved through [Content_Types].xml. An image whose measured pixel area reaches limits.minRasterTextArea is disclosed wherever it sits in the package; a part inside a media/ directory that cannot be measured falls back to its real inflated length against limits.minRasterTextBytes, and a declared size must be credible for a part that big. Parts the engine did in fact read come off the list — a transcribed image, a parsed SVG, a recognised metafile. One informational disclosure per document listing each part with its dimensions, action: "disclosed", chars: 0; nothing is stripped or flagged, and certified goes false.
How often it fires
Not measured. We publish a rate only where one has been measured against a named corpus of the right format, and no figure exists for this technique yet. Absence means unknown — never low.
Check your own file
Three commands: a key, credit, a verdict.
Start with the API