Security policy

Reporting a vulnerability in Xila

Email security@xila.us with a description, affected version, and a reproduction. Do not open a public issue for a vulnerability in Xila itself.

We acknowledge within 3 working days, agree a fix window with you, credit you in the release notes unless you prefer otherwise, and publish an advisory when the fix ships.

Xila parses hostile input by design. Bugs we treat as security issues:

• Memory or CPU exhaustion from a crafted build, bundle, .pck, archive or rule (an unbounded allocation, a decompression bomb, a pathological rule).
• Path traversal while extracting a container (writing or reading outside the artifact root).
• A secret appearing unredacted in any report, log line or error message.
• An external module escaping its declared permissions through the host.
• A prober running without a valid authorization reference.

Reporting a vulnerability you found with Xila, in someone else's game

Xila runs on builds you already have. Finding a leaked key in a game you do not work on creates an obligation, not a publication opportunity.

1. Do not use the credential. Reading a database with a key you found is unauthorized access, whatever the key was doing in the build.
2. Contact the developer privately. Their security contact, a published security.txt, their support address, or the storefront's developer contact form. Explain what is exposed, where, and what to do about it.
3. Rotation first. The fix is almost always: revoke the key, move the privileged call to a server, ship an update. Say that plainly.
4. Give them time. 90 days is a reasonable default for a full fix; a key rotation usually takes hours, not months. Agree a date.
5. Never publish specifics before a fix. No key prefixes, no endpoint paths, no "redacted" screenshots that still identify the value. A finding that lets a reader reproduce the access is not redacted.
6. Never publish the credential at all, before or after.

If you cannot reach the developer, contact the platform the game ships on. If you cannot reach anyone, write to disclosure@xila.us and we will try through industry channels.

Research we publish

Xila publishes research about classes of problem, using our own deliberately vulnerable sample builds (https://github.com/xilasec/xila-testdata) for every concrete example. Real games appear only with the developer's written consent, after a fix has shipped.

Scope of Xila itself

Xila is static and offline: it reads files you point it at, makes no network requests (a module that declares network access does not run without --allow-network), and sends no telemetry. Findings never leave your machine unless you upload the report yourself.