Dominik Schmidt created TIKA-4826:
-------------------------------------
Summary: MimeTypes.forName interns unknown media types into an
unbounded map (slow memory growth on untrusted-input paths)
Key: TIKA-4826
URL: https://issues.apache.org/jira/browse/TIKA-4826
Project: Tika
Issue Type: Bug
Reporter: Dominik Schmidt
MimeTypes.forName(String) (tika-core, MimeTypes.java:351) is called during
content detection to turn a type hint into a MimeType: MimeTypes.detect runs
applyHint, which calls forName(typeName) for the caller's Content-Type. For a
syntactically valid but unknown type, forName creates a new MimeType and
registers it via add(mime) / types.put(...) into an internal map that is never
bounded or evicted (lines 359-369).
A caller that can influence the type string reaching detection can therefore
drive slow, unbounded memory growth by sending a stream of unique,
syntactically-valid, unknown media types (for example application/x-<random>).
This is reachable today from the tika-server request Content-Type on the direct
endpoints, and TIKA-4825 adds the tika-pipes FetchEmitTuple path as another
route to the same lookup.
Severity is low (it needs many requests with distinct crafted types, and growth
is slow), but it is an avoidable footgun on an untrusted-input path, and it is
a shared/static registry so growth persists for the JVM lifetime.
Proposed fix: use a non-registering lookup in the detection path. applyHint
only needs to know whether the hinted type equals or specializes a known type;
it does not need to intern unknown types. Either add a
MimeTypes.detect/applyHint variant that resolves a hint against the existing
registry without adding, or bound/evict the registration map.
Note: discovered during review of TIKA-4825 (apache/tika#3039); flagged there
as pre-existing and out of scope for that PR.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
