Aelira Core v0.9.12: publishing the security record with the release

Why this release leads with security

Aelira Core v0.9.12 contains the document and review work we have described in recent updates. It also contains security fixes, and we are publishing three security advisories alongside it.

One of those advisories describes a vulnerability fixed in this release. One describes a fix we merged and deployed to our hosted service in October, which reaches self-hosted installations with this release. The third describes problems we fixed in v0.9.4 in August, but never published as an advisory. That was our mistake, and this release corrects the record.

LaTeX conversion could read files outside the submission

Aelira converts submitted LaTeX documents with LuaLaTeX, pdflatex, LaTeXML and pandoc. In v0.9.11 and earlier, a submitted document could make those tools read files outside its own directory, and the contents could appear in the converted output. The tools also inherited the application's full environment.

On an affected installation this could expose other uploaded documents, and keys or configuration readable by the application user. The details are in GHSA-53gp-pqcg-h8q4.

In v0.9.12, each tool starts under a Linux Landlock ruleset. It can read the submitted source and the system files it needs, write only inside its own conversion directory, and receives a minimal environment. If the kernel or container runtime does not provide Landlock, the tools do not run, and LaTeX conversion reports them as unavailable. It does not fall back to running them unconfined.

The tests run the real tools against legitimate documents and against documents that name files outside the permitted directories. Each boundary case has a positive control, so a test cannot pass simply because nothing was read. The full test suite ran on both x86-64 and ARM64 before the fix was merged.

On our hosted service, we switched the LaTeX tools off on 15 October while the fix was prepared, and the confined version is now deployed there. LaTeX conversion stays switched off on the hosted service for now. Our free demo accepts files from anyone without an account, and the ten unfixed advisories described below can only be reached through LaTeX conversion. We are following the same advice we give self-hosted operators who accept LaTeX from people they do not know: keep it off until fixed packages are available.

If you self-host Aelira Core 0.9.11 or earlier, upgrade. If you cannot upgrade yet, the advisory describes how to disable LaTeX remediation until you can.

Two more advisories

GHSA-pxvh-7g4g-rjrp covers web scanning in versions 0.9.0 to 0.9.11, which could make server-side requests to internal network addresses. The fix is part of the hardening we described after our CodeQL review. It was deployed to the hosted service on 8 October and ships to self-hosted installations in this release.

GHSA-hg83-758v-p8p9 covers two Canvas integration flaws in v0.9.3 and earlier: an OAuth callback that could disclose the Canvas client secret, and LTI learner launches that could receive staff authority. Both were fixed in v0.9.4 on 19 August. We drafted the advisory then, but did not finish and publish it. If you ran 0.9.3 or earlier with Canvas OAuth enabled, rotate the Canvas developer key's client secret and review your Canvas write-back history.

Unfixed advisories, disclosed rather than hidden

The release workflow scans each native image and refuses to publish with a fixable HIGH or CRITICAL finding. Some Debian packages in the API image have advisories with no Debian fix yet. For those, the only way through the gate is a reviewed, expiring and published disposition.

There are 65 of them in this release. 55 are not affected in this image, with a stated reason the vulnerable code cannot be reached. One of those is a critical libxml2 advisory, which the LaTeX confinement made unreachable.

The other 10 are affected. Seven are in libxml2, the XML library LaTeXML uses, and three are denial-of-service issues in ImageMagick and libtiff, which can process graphics a LaTeX document refers to. All 10 are reached only when Aelira converts a LaTeX document that someone has submitted, with one exception. The application calls these tools only for LaTeX conversion, and its own XML processing uses a separately built, patched libxml2. A PDF that contains LaTeX maths does not reach them: maths in PDFs and web pages is converted by a separate Python library. The exception is the libtiff denial-of-service issue, CVE-2026-36849: the Pillow imaging library bundles its own copy of libtiff, so a crafted TIFF image inside an uploaded file can also reach it. No Pillow release with a fixed libtiff is available yet.

Every finding stays in the published scan reports, and each review expires on 12 January

1. The full list, with packages and reasoning, is in

known unfixed advisories in v0.9.12. A clean scanner report would not prove an image is safe, and this list does not claim that either.

Using v0.9.12 safely while those fixes are pending

Disclosure is only useful if it comes with something you can act on. This is what limits the exposure, and what we recommend.

What already limits it. Only signed-in users can submit documents, and a self-hosted installation has no public sign-up unless an operator deliberately sets OPEN_SIGNUP=true. In v0.9.12 every LaTeX tool runs under the Landlock boundary described above: it can read only the submission and the system files it needs, write only to its own conversion directory, and has no application configuration or secrets in its environment. A problem in one of these libraries during conversion therefore has far less within reach than it would have had in 0.9.11. The provided reverse-proxy configuration also applies a stricter rate limit to upload routes, including LaTeX.

What we recommend:

• Decide who may submit LaTeX. If only staff you trust submit LaTeX documents, the

remaining risk is limited. If your installation accepts LaTeX from people you do not trust, or you cannot accept the remaining risk, disable LaTeX remediation until fixed packages are available. Make latexml, latexmlpost, lualatex, pdflatex and pandoc unavailable to the API and worker containers, as the LaTeX advisory describes. Turning LaTeX off leaves PDF, Office, video and web scanning available. It does not remove the TIFF denial-of-service exposure, which the memory and CPU limits below contain.

• Keep sign-up closed unless you intend to run an open installation.
• Set memory and CPU limits on the API and worker containers, and keep the provided

upload rate limits, so a stalled or crashing conversion cannot starve the host.

• Watch for the fixes. Use GitHub's Watch → Custom → Releases and Security alerts on

the repository. We will publish a release when Debian ships fixes, and the release gate will not accept these reviews after they expire.

A working file while manual work remains

When remediation verifiably improves a PDF but manual corrections remain, the improved file can now be downloaded as a working file. Review shows the applied changes, pending decisions and remaining work. Downloading it does not approve it for publication, and writing it back to an external system still requires a person to approve the current file.

Supported PDF structure edits now become candidates for review. Rebuilding applies the accepted edits and leaves out the rejected ones. Remediation confidence that is unknown now stays unknown, rather than becoming zero or an invented high score.

What operators need to do

This release adds two database migrations. Before upgrading, pause new work, drain the worker and take a coordinated backup of the database, uploads, artifacts and matching configuration and keys. Read the historical confidence correction, because the migration can revoke some earlier approvals.

Upgrade the API, worker and dashboard together from the same release, and run alembic upgrade head before accepting traffic. Do not roll back a single service. A return to 0.9.11 means restoring the matching backup as a whole. The release notes give the full procedure.

The v0.9.12 release provides native x86-64 and ARM64 images with signed provenance, the CLI through npm trusted publishing with provenance, and a seven-file SBOM bundle.

An automated score describes the checks we implemented. It does not establish accessibility conformance, and the saved document still needs review before publication.

The whole self-hosted product remains free and open source. Download Aelira Core v0.9.12 and read the upgrade guidance.