- What: Doyensec performed a security audit of the Outline OSS wiki, comparing manual testing with AI security platforms.
- Why: To evaluate the application's overall security posture and compare different audit methodologies.
- Impact: The security posture of the APIs was found to be above industry best practices.
We aresecurity engineerswho break bits and tell stories.Visit usdoyensec.comFollow us@doyensecEngage usinfo@doyensec.com © 2026Doyensec LLC In July 2025, we performed a brief audit ofOutline- an OSS wiki similar in many ways to Notion. This activity was meant to evaluate the overall posture of the application, and involved two researchers for a total of 60 person-days. In parallel, we thought it would be a valuable firsthand experience to use three AI security platforms to perform an audit on the very same codebase. Given that all issues are now fixed, we believe it would be interesting to provide an overview of our effort and a few interesting findings and considerations. While this activity was not sufficient to evaluate the entirety of the Outline codebase, we believe we have a good understanding of its quality and resilience.The security posture of the APIs was found to be above industry best practices. Despite our findings, we were pleased to witness a well-thought-out use of security practices and hardening, especially given the numerous functionalities and integrations available. It is important to note that Doyensec audited only Outline OSS (v0.85.1). On-premise enterprise and cloud functionalities were considered out of scope for this engagement. For instance, multi-tenancy is not supported in the OSS on-prem release, hence authorization testing did not consider cross-tenant privilege escalations. Finally, testing focused on Outline code only, leaving all dependencies out of scope. Ironically, several of the bugs discovered were actually caused by external libraries. Large Language Models and AI security platforms are evolving at an exceptionally rapid pace. The observations, assessments, and experiences shared in this post reflect our hands-on exposure at a specific point in time and within a particular technical context. As models, tooling, and defensive capabilities continue to mature, some details discussed here may change or become irrelevant. When performing an in-depth engagement, it is ideal to set up a testing environment with debugging capabilities for both frontend and backend. Outline’s extensive documentation makes this process easy. We started by setting up a local environment as documented inthis guide, and executing the following commands: The following.envfile was used for the configuration(non-empty settings only): Zitadel’sOIDC serverwas used for authentication Finally, VS Code debugging was set up using the following.vscode/launch.json We also facilitated front-end debugging by adding the following setting at the top of the.babelrcfile in order to have source maps. Doyensec researchers discovered and reportedseven (7) unique vulnerabilitiesaffecting Outline OSS. Among the bugs we discovered, there are a few that require special mention: OUT-Q325-01(GHSA-jfhx-7phw-9gq3) is a standard Server-Side Request Forgery bug allowing redirects, but having limited protocols support. Interestingly, this issue affects the self-hosted version only as the cloud release is protected usingrequest-filtering-agent. While giving a quick look at this dependency, we realized that versions 1.x.x and earlier contained a vulnerability (GHSA-pw25-c82r-75mm) where HTTPS requests to 127.0.0.1 bypass IP address filtering, while HTTP requests are correctly blocked. While newer versions of the library were already out, Outline was still using an old release, since no GitHub (or other) advisories were ever created for this issue. Whether intentionally or accidentally, this issue was silently fixed for many years. OUT-Q325-02(GHSA-pp7p-q8fx-2968) turned out to be a bug in thevite-plugin-static-copynpm module. Luckily, it only affects Outline indevelopmentmode. OUT-Q325-04(GHSA-gcj7-c9jv-fhgf) was already exploited in thistype confusion attack. In fact, browsers like Chrome and Firefox do not block script execution even if the script is served withContent-Disposition: attachmentas long as the content type is a validapplication/javascript. Please note that this issue does not affect the cloud-hosted version given it’s not using the local file storage engine altogether. Investigating this issue led to the discovery ofOUT-Q325-06, an even more interesting issue. Outline allows inline content for specific (safe) types of files as defined inserver/storage/files/BaseStorage.ts Despite this logic, the actual content type of the response was getting overridden. All Outline versions before v0.84.0 (May 2025) were actually vulnerable to Cross-Site Scripting because of this issue, and it was accidentally mitigated by adding the following CSP directive: