CVE-2025-0781 is a high severity sandbox bypass (CVSS 8.6) in FlightGear and SimGear. A Nasal script can write to any file the user may modify. Update both packages. Debian 11 fixed it in 1:2020.3.6+dfsg-1+deb11u1.
What's affected
- Products: FlightGear (the flight simulator) and SimGear (the library it is built on). Debian Linux also appears in the record.
- Weakness: CWE-863, incorrect authorization.
- Fixed in Debian 11 bullseye: version
1:2020.3.6+dfsg-1+deb11u1for both thesimgearandflightgearpackages, per two Debian LTS advisories. - Upstream fixes: two commits, one in the SimGear repository and one in the FlightGear repository, both linked from the record.
- Upstream release number that first contains the fix: not confirmed here. Check the FlightGear release notes.
- CISA KEV: not listed.
The impact is described plainly in the record: an attacker can bypass the sandbox that restricts Nasal scripts, and write to any path the operating system lets the user modify. The CVSS vector is local, with user interaction required and a changed scope. That fits the way FlightGear works. Scripts and add-ons are loaded by the user, so the realistic path is a script or aircraft package that the user chooses to run.
How to check if you're exposed
- On Debian or Ubuntu, run
dpkg -l | grep -E 'flightgear|simgear'and compare versions with the Debian advisory. - On other systems, check the version from the application's About screen or the package manager.
- List the add-ons, aircraft and scripts you have installed from outside the official repositories. Those are the likely carriers of Nasal code.
- Check for unexpected changes to files in your home directory, such as shell startup files or configuration, if you have run unknown add-ons.
What to do now
- Update FlightGear and SimGear through your package manager. On Debian 11, move to 1:2020.3.6+dfsg-1+deb11u1 or later.
- If you build from source, update to a revision that includes the two fix commits.
- Install aircraft and add-ons only from sources you trust, and review scripts you did not write.
- Run the simulator as a normal user, never as root, and keep sensitive files out of that user's write access where you can.
- Servers or shared machines that host FlightGear for others should treat user supplied scripts as untrusted until updated.
Why it matters
Sandboxes exist so that code you load can do a small set of things. Here, the file path rules were not applied when a Nasal value was turned into a path object in the library. The SimGear commit message says it adds a check of the I/O rules when a path is built automatically from a Nasal scalar, and moves the check into a shared function. In plain terms, a rule existed but one route skipped it.
That is a good example of an authorization gap. The fix does not change the design. It makes sure every route goes through the same check. When you review your own software that runs plugins, ask the same question: is there any path that reaches the dangerous operation without passing the gate?
Overwriting arbitrary files can lead to a lot, from corrupted data to a changed startup file that runs later. The record does not say this has been used in attacks, and it is not in CISA KEV.
Quick check
Do I need to worry if I only fly with the built in aircraft?
The risk is from running a script that abuses the sandbox gap. Built in content is far less likely to carry that, but updating removes the question.
What is the fixed version on Debian?
For Debian 11 bullseye, the LTS advisories give 1:2020.3.6+dfsg-1+deb11u1 for both simgear and flightgear.
Sources
- Debian LTS advisory for simgear
- Debian LTS advisory for flightgear
- SimGear fix commit
- NVD record for CVE-2025-0781
Last reviewed: 19 October 2026.
