fix(media): restore AVIF to the default upload allowlist - #2683
Merged
Conversation
emdash-cms#2250 replaced the bare "image/" prefix match in GLOBAL_UPLOAD_ALLOWLIST with an explicit enumeration of safe raster types, so that image/svg+xml would stop being accepted by default. image/avif was covered by the old prefix match but was not carried into the enumeration, so AVIF uploads started failing with "File type not allowed". Both media serving paths already treat image/avif as safe to render inline, so the upload gate was the only place that disagreed about AVIF. Restoring it there is what unblocks the upload; the extension shorthand and the admin picker's accept filter are the other two places a .avif file gets turned away before it reaches that gate. SVG stays excluded. Closes emdash-cms#2602
🦋 Changeset detectedLatest commit: 9891b85 The changes in this PR will be included in the next version bump. This PR includes changesets to release 17 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
![emdashbot[bot]](https://avatars.githubusercontent.com/in/3255304?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
This is the right fix for the right problem. Restoring image/avif to the upload gate is the minimal, safe way to resolve the regression from #2250 without weakening the SVG exclusion that motivated that earlier security change.
I checked the changed files and traced the relevant call sites:
GLOBAL_UPLOAD_ALLOWLISTnow includesimage/avif; the upload routes inpackages/core/src/astro/routes/api/media.tsandapi/media/upload-url.tsfall back to this list, and the existing inline-serving routes (routes/api/media/file/[...key].ts,media/image-endpoint.ts, and the plugin artifact route) already list AVIF as a safe inline type, so the upload gate was the only outlier.- Both
EXTENSION_TO_MIMEmaps (core and admin) include.avif→image/avif, so field-levelallowedMimeTypesusing extension shorthand works. - The admin upload dialog’s
acceptattribute andPREVIEW_MIME_TYPESset include AVIF, and the built-in "Images" preset inAllowedTypesEditorincludes it too. - The changeset (
emdashand@emdash-cms/adminpatch) is accurate, user-facing, and names the observable behavior and affected audience. - The docs table is updated to match the new default allowlist.
- Tests were added for both the allowlist membership and the extension shorthand expansion, framed as regressions against the media routes’ existing AVIF support.
No new user-facing strings were added, so no Lingui or RTL/Tailwind work is required. No database queries or logged-out routes are affected. The implementation is scoped, consistent, and leaves SVG excluded.
LGTM — no findings.
github-actions
Bot
added
area/admin
area/core
area/docs
size/S
review/approved
Contributor
|
All contributors have signed the CLA ✍️ ✅ |
ascorbic
enabled auto-merge (squash)
August 26, 2026 14:45
@emdash-cms/admin
@emdash-cms/auth
@emdash-cms/auth-atproto
@emdash-cms/blocks
@emdash-cms/cloudflare
@emdash-cms/contentful-to-portable-text
emdash
create-emdash
@emdash-cms/gutenberg-to-portable-text
@emdash-cms/plugin-cli
@emdash-cms/plugin-types
@emdash-cms/registry-client
@emdash-cms/registry-lexicons
@emdash-cms/registry-moderation
@emdash-cms/registry-verification
@emdash-cms/sandbox-workerd
@emdash-cms/x402
@emdash-cms/plugin-ai-moderation
@emdash-cms/plugin-atproto
@emdash-cms/plugin-audit-log
@emdash-cms/plugin-color
@emdash-cms/plugin-embeds
@emdash-cms/plugin-field-kit
@emdash-cms/plugin-forms
@emdash-cms/plugin-webhook-notifier
commit: |
Contributor
Author
|
I have read the CLA Document and I hereby sign the CLA |
Contributor
Author
|
recheck |
1 similar comment
Contributor
Author
|
recheck |
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
2 participants
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 does this PR do?
AVIF uploads fail with
File type not allowed.image/avifis missing from the default media allowlist, so a.aviffile is rejected before it ever reaches storage.Root cause. The regression came from #2250, not from the commit named in the issue. #2250 replaced the bare
"image/"prefix match inGLOBAL_UPLOAD_ALLOWLISTwith an explicit enumeration of safe raster types so thatimage/svg+xmlwould stop being accepted by default — a deliberate and correct security fix, since there is no upload-time content validation for SVG.image/avifwas covered by the old prefix match but was not carried into the new enumeration.ffaadc4(#2553) later aligned the adminacceptattribute and the docs table with that shortened list, which is why the issue points there.The rest of the codebase already treats AVIF as a supported inline raster type —
SAFE_INLINE_TYPESinroutes/api/media/file/[...key].tsandSAFE_INLINE_IMAGE_TYPESinmedia/image-endpoint.tsboth listimage/avif. EmDash would serve an AVIF inline but refuse to accept one; the upload gate was the only place that disagreed.The change.
image/avifis restored in the three places a.aviffile is turned away:GLOBAL_UPLOAD_ALLOWLIST— the server-side gate that produces the errorEXTENSION_TO_MIMEin core and admin — so.avifworks as extension shorthand in a field'sallowedMimeTypesacceptfilter and thumbnail preview set, plus the built-in "Images" preset in the allowed-types editorSVG stays excluded from the default allowlist — #2250's protection is untouched.
Closes #2602
Type of change
Checklist
pnpm typecheckpassespnpm lintpassespnpm testpasses (or targeted tests for my change)pnpm formathas been runmessages.pochanges are included.patchforemdashand@emdash-cms/admin)AI-generated code disclosure
Screenshots / test output
Both new assertions were written first and observed failing against the unfixed allowlist:
After the fix, the full core media suite passes:
pnpm lint(oxlint --type-aware --deny-warnings) exits clean, andpnpm typecheckpasses.One note on the full
pnpm --filter emdash testrun: 18 tests across 10 files fail in my local Windows environment (path-separator assertions,pnpm-symlink resolution, systemtar, file-based SQLite). I verified these fail identically on an unmodifiedmaincheckout — same 18 failures, same 10 files — so they are pre-existing and unrelated to this change. Every media test passes.