You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Request: backport CVE-2026-82035 fix (b2c8f3a) to a 1.28.x patch release #5208
CVE-2026-82035 / Ghostscript bug 709683 (path traversal and arbitrary file
write via extract_objects()'s font branch in src/__main__.py) was fixed
in commit b2c8f3a on the 2.0 release. The last 1.x release, 1.28.2,
predates the fix and remains vulnerable.
2.0 bumps MuPDF to 1.28.5 and changes the supported Python range, which
makes it a non-trivial upgrade for projects pinned to the 1.x line for
dependency/compatibility reasons. Since the fix itself is a minimal,
self-contained change (5 lines, no new dependencies, no API changes), would
you consider backporting it as a 1.28.3 (or similar) patch release on the 1.x line?
I verified that b2c8f3a cherry-picks cleanly onto the 1.28.2 tag with no
conflicts, and confirmed with a crafted PDF that:
the unpatched 1.28.2 code writes a font file outside the requested output
directory when BaseFont contains encoded ../ sequences, and
the cherry-picked fix prevents the escape (slashes/backslashes are
replaced before the path join, same as the 2.0 fix).
Happy to open a PR with just this cherry-pick against a 1.28.x branch/tag
if that's useful — let me know which branch you'd like it targeted at.
I tried to open a PR but GitHub requires a branch as the base, and there's no 1.28.x maintenance branch upstream to target (main has already diverged for 2.0, so a PR against it would be noisy and not a clean backport). If you can point me at (or create) a maintenance branch based on 1.28.2, I'll retarget/open the PR against it right away. Otherwise this commit is ready to cherry-pick directly whenever a 1.28.x release is cut: https://github.com/jasonmelehani16/PyMuPDF/tree/backport-1.28.x
julian-smith-artifex-com commented on Oct 26, 2026
Python-3.10 is now end-of-life (https://devguide.python.org/versions/) so, like many other Python projects, we no longer support it in any way. So you'll need to move to python>=3.11 to continue to use the latest release of pymupdf.
And as you have noticed, we don't have maintenance branches. Pymupdf is quite a complicated product, consisting of multiple wheels (pymupdf, pymupdf-lite, pymupdf-office) for various platform/cpu combinations (Windows, Linux, MacOS, Pyodide; x32, x64, arm64) which variously pull in other wheels and third-party code such as onnxruntime, tesseract etc. Maintaining multiple releases simultaneously would require significant extra effort, which would impact our work on bug fixes and the development of new features.
I think this also keeps things simpler for users - just use the latest version, always.
Activity
jasonmelehani16 commentedon Oct 24, 2026
I have the cherry-pick ready: jasonmelehani16@f5648a8c (b2c8f3a applied cleanly onto the
1.28.2tag, no conflicts).I tried to open a PR but GitHub requires a branch as the base, and there's no
1.28.xmaintenance branch upstream to target (mainhas already diverged for 2.0, so a PR against it would be noisy and not a clean backport). If you can point me at (or create) a maintenance branch based on1.28.2, I'll retarget/open the PR against it right away. Otherwise this commit is ready to cherry-pick directly whenever a 1.28.x release is cut: https://github.com/jasonmelehani16/PyMuPDF/tree/backport-1.28.xjulian-smith-artifex-com commentedon Oct 26, 2026
Python-3.10 is now end-of-life (https://devguide.python.org/versions/) so, like many other Python projects, we no longer support it in any way. So you'll need to move to python>=3.11 to continue to use the latest release of pymupdf.
And as you have noticed, we don't have maintenance branches. Pymupdf is quite a complicated product, consisting of multiple wheels (pymupdf, pymupdf-lite, pymupdf-office) for various platform/cpu combinations (Windows, Linux, MacOS, Pyodide; x32, x64, arm64) which variously pull in other wheels and third-party code such as onnxruntime, tesseract etc. Maintaining multiple releases simultaneously would require significant extra effort, which would impact our work on bug fixes and the development of new features.
I think this also keeps things simpler for users - just use the latest version, always.
Apologies if this seems unhelpful.