CVE-2026-34444 is a critical (CVSS 10.0) bypass of the attribute_filter in Lupa, the Python library that embeds Lua. The filter is not applied to getattr and setattr, which can lead to code execution. The advisory lists no patched version, so do not rely on the filter.
What's affected
The project's advisory (GHSA-69v7-xpr6-6gjm) lists the pip package lupa at version 2.6 and later as affected, with no patched version. The NVD record states 2.6 and earlier. Red Hat lists an erratum, RHSA-2026:22993, so a distribution build may carry a fix. Check its page.
The feature in question is attribute_filter. It is meant to block access to sensitive Python attributes such as __class__ and __mro__ when Python objects are exposed to Lua. The advisory says the filter only applies to direct attribute access. Access through Python's getattr and setattr built-ins is not filtered consistently, so the filter can be bypassed.
This matters only if you run Lua code you do not fully trust and expose Python objects to it.
How to check if you're exposed
pip show lupa
pip freeze | grep -i lupa
Then look at how your code uses it. Search for attribute_filter and for any place where Python objects, functions or modules are passed into a Lua runtime. If Lua scripts come only from your team, risk is lower. If they come from users, plugins or models, you are in the case the advisory describes.
Paste a lockfile or manifest into the free in-browser dependency scan to see whether the package is in your tree, including as a transitive dependency. Reachability analysis then helps you judge whether your code calls the affected path, so you can order the work sensibly.
Draw up an inventory of Lua use. Search repositories for import lupa, from lupa import and for LuaRuntime(. Note, for each hit, whether the Lua code is written by your team or by others, and which Python objects are exposed. A runtime that receives only plain data, with no Python objects, is not the case the advisory describes.
What to do now
- Find the projects that import
lupa, including through other packages. - Check the advisory and your distribution for a fixed release before relying on one.
- Stop treating
attribute_filteras a security boundary for untrusted Lua. - Run untrusted scripts in a separate low-privilege process, container or VM, with no secrets and limited network access.
- Expose the smallest possible set of Python objects, wrapped in plain functions that do one thing.
- Re-check the advisory periodically for a patched release.
- Subscribe to the project's releases so you hear when a patched version appears.
Why it matters
The record lists CWE-284 (improper access control), CWE-639 (authorization bypass through user-controlled key) and CWE-914 (improper control of dynamically identified variables). The common thread is that the check lived at one layer, direct access, while an equivalent route through built-in functions skipped it.
This is the standard weakness of denylist-style sandboxes in dynamic languages. Python exposes many routes to the same attribute, and an exposed object often leads to the interpreter itself. A filter that blocks some routes gives a false sense of safety. Real isolation puts the untrusted code in a process that has nothing worth stealing.
With no upstream fix listed, your options are mitigation and isolation. The record does not mark the CVE as exploited, and it is not on the CISA KEV list.
If you must run untrusted Lua, design for the filter failing. Give the interpreter process its own user account, an empty working directory and no environment secrets. Limit its CPU time and memory with the operating system's resource controls, and cut its network access where you can. Pass data in and out as plain values, such as JSON, rather than sharing live Python objects.
That architecture costs some convenience, but it turns a total compromise into a crash in a disposable process. It also protects you from the next bypass, which is likely to come, because attribute filters in dynamic languages are a hard thing to get right.
Track the issue. The advisory lists no patched version today, so watch the project's releases and the advisory page for changes, and apply a fix when one appears. Because Red Hat lists an erratum for this CVE, distribution users should also read their vendor notice.
Some teams use the Lua runtime from Python to let customers write small rules. If that is you, ask whether those rules need Python objects at all. Often a table of plain values and a few registered functions is enough, and that design makes the filter question moot. Write the rules interface as a narrow contract, test it with hostile inputs, and keep a record of which version of the library each deployment runs. If a vendor or integrator supplies the Lua runtime for you, ask them directly which version it uses and what their plan is.
Quick check
Is there a patched version of Lupa?
The advisory lists none. Check for a distribution fix, and isolate untrusted Lua rather than relying on the filter.
Sources
Last reviewed: 19 October 2026.
