Repository navigation
Conversation
…e#18412) Absolute paths made only of Base64-alphabet characters (e.g. /etc/passwd, /usr/bin/env) were classified as Base64 and then rejected or silently decoded into garbage. - classify_input() now returns ABSOLUTE_PATH for an existing absolute path before trying the Base64 check. - is_base64() requires a length that is a multiple of 4 and a successful strict decode. - infer_file_type_from_bytes() returns None for unidentifiable bytes instead of leaking puremagic.PureError. - The unsupported-content error hints that a '/'-prefixed input may be a missing file. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
|
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
classify_input()testedis_base64()before checking for a file path. On POSIX,/is in the Base64 alphabet, so an existing absolute path made only of alphanumerics and/(e.g./etc/passwd,/usr/bin/env) was treated as Base64:Invalid Base64 input: Incorrect padding/usr/bin/env) → silently decoded into garbage and then rejected (with the currentpuremagicthis surfaced as an uncaughtPureError: Could not identify file)Changes
input_contract.classify_input(): returnABSOLUTE_PATHfor an absolute path (after~expansion) that exists, before the Base64 check. Paths are only preferred when they exist, so Base64 payloads that start with/(every JPEG starts with/9j/) are still classified as Base64.utils.is_base64(): also requirelen(value) % 4 == 0and a successfulbase64.b64decode(..., validate=True). This is consistent withdecode_base64_payload(), which already used strict decoding, so no previously decodable input is rejected.utils.infer_file_type_from_bytes(): returnNonewhenpuremagiccannot identify the bytes, so callers produce the intended "Unsupported Base64 content type" error instead of aPureError.If '<value>' is a file path, the file does not exist.when the input starts with/, covering a missing alphabet-only path that is still valid Base64.Tests
tests/unit/test_mcp_input_contract.pycoversis_base64()edge cases, existing alphabet-only paths (/etc/passwd,/usr/bin/env,/bin/sh, skipped if absent), raw PNG Base64, Base64 starting with/9j/, and the missing-path error. 6 of these fail onmainand all pass with the fix.The module skips itself when
fastmcp/puremagicare not installed.tests.ymldoes not install the MCP server's dependencies today, so CI will skip it unlesspip install -e mcp_serveris added; I can add that in this PR if you'd like.Fixes #18412
🤖 Generated with Claude Code