Please start by reading these links to understand our existing security model, known issues, API surfaces, and setup steps:

• https://github.com/ArchiveBox/ArchiveBox/wiki/Security-Overview
• https://github.com/ArchiveBox/ArchiveBox/security/advisories/
• https://github.com/ArchiveBox/ArchiveBox/tree/v0.7.4#security-risks-of-viewing-archived-js
• https://github.com/ArchiveBox/ArchiveBox/wiki/Publishing-Your-Archive#security-concerns
• https://github.com/ArchiveBox/ArchiveBox/wiki/Setting-up-Authentication
• https://github.com/ArchiveBox/ArchiveBox#archive-layout
• https://github.com/ArchiveBox/ArchiveBox#archivebox-development
• https://github.com/ArchiveBox/ArchiveBox/wiki/Upgrading-or-Merging-Archives
• https://github.com/ArchiveBox/ArchiveBox/wiki/Troubleshooting

We use Github's built-in Private Reporting feature to accept vulnerability reports. We no longer offer CVEs or accept private reporting, 95% of the reports we received were low quality AI slop, so now we just ask for normal Github Issues or PRs.

You can contact the maintainers via our public Zulip Chat Server zulip.archivebox.io or Twitter DMs @ArchiveBoxApp if you have a truly urgent security report, but we do not issue public CVEs.

Please read our existing published security advisories, Security Overview Docs, and issues and avoid creating duplicates.

ArchiveBox does not support granular user permissions, there are only two types of users available in the Admin UI & REST API:

• logged in admin superusers (which are assumed to have root on the ArchiveBox host machine already)
• non-logged in anonymous guest users

Because admin / REST API / CLI / Python API users are already assumed to have root on the host machine, there are deliberately no protections against admins inputting malicious config values, attempts to attack other admin users, or destructive/malicious actions. Permissions for non-logged in users are managed via the PERMISSIONS + PUBLIC_INDEX + PUBLIC_ADD_VIEW + other config options.

Non-logged in users can only choose between public Persona config presets on the /add/ page, but they should never be allowed to directly set config options like *_ARGS, *_BINARY or DB fields like url, title, tag.name, notes without sanitization/filtering on save and/or use.

Non-logged in users should be tightly limited to prevent attacks like SQL/shell injection, path traversal attacks, XSS, cookie leaks between admin/non-admin domains, etc. Any reports related to non-logged-in users will be prioritized as this is a surface we care a lot about hardening.

< v0.9.x versions do not include any XSS/CSRF protections at all, as documented in the readme, wiki, issue #239, and existing advisory. Do not open advisories related to XSS or CSRF for those versions, as they are missing fundamental architectural changes added in v0.9.0 needed to support per-snapshot replay isolation.

SERVER_SECURITY_MODE + CSRF/XSS defenses were only added in the new 0.9.0 dev work and are planned to land in main in mid-2026.

Note archivebox is designed to be able to archive any URL the server can reach, including internal intranet URLs, private IPs, and localhost. Users are expected to configure URL_ALLOWLIST/URL_DENYLIST or proper firewall/ACL-level blocking at the network level if they need to limit what the server should see. It does a basic check to try and avoid recursively archiving snapshots hosted by the archivebox server itself, but it's not a strict security check, it's just to prevent wasted CPU/disk from recursively archiving snapshots in a browser that has the ArchiveBox Browser Extension turned on.