Catch the vulnerability before it ships.
Polylane reviews every pull request that reaches production for flaws an attacker can exploit. It traces each finding from input to sink in your code, and drops the ones it can rule out.
No credit card required.
Review
It reviews every change that reaches production
Each pull request gets a Polylane security review check and a security section in the Polylane comment, alongside the impact analysis. A confirmed critical or high finding puts the merge on hold, with the file, the line and the fix.
Start reviewing 
Add CSV export for invoices #318
main from invoice-csv-export 
Hold this merge. 1 high security finding.
| Check | Result |
|---|---|
| Impact assessment | Passed |
| Security review | Hold · 1 high |
Security review
- High Invoice export returns another account's invoices
src/routes/invoices/export.ts:42Fix: Usesession.accountIdand ignoreaccountIdin the query string.
View the full security review →
Impact assessment
This change is unlikely to harm production
Polylane analysed b4e1c07 for production impact and security.
Trace
It proves each finding or rules it out
Pattern matchers flag the places worth a look. Polylane follows each one from the input an attacker controls to the line it reaches, and drops it when a check on the path makes it safe.
See the evidence- Finding
- Invoice export returns another account's invoices src/routes/invoices/export.ts:42
- Mechanism
- A signed-in user sets
accountIdin the query string. The handler passes it tolistInvoicesunchecked, so the CSV holds that account's invoices. - Evidence
-
- src/routes/invoices/export.ts:31 reads
accountIdfromreq.query - src/routes/invoices/export.ts:42 calls
listInvoices(accountId, range)with no ownership check - src/db/invoices.ts:18 filters on the account id it is given, nothing else
- src/routes/invoices/export.ts:31 reads
- Fix
- Use
session.accountIdand ignoreaccountIdin the query string.
from and to are bound parameters, and src/routes/invoices/export.ts:35 rejects anything but ISO dates.
escapeHtml at src/lib/escape.ts:9 escapes the memo before it is rendered.
Fix
It patches vulnerable dependencies on the repos you deploy
A daily scan finds vulnerable dependencies, files the most severe first, and opens a fix pull request only on repositories that are active and deployed.
Start fixingUpgrade next to 15.2.3 to close the middleware bypass #1304
polylanemain from polylane/autofix/v8k2m4q7x1za storefront runs next 15.1.7, which has a critical advisory, CVE-2025-29927: a request with an x-middleware-subrequest header skips middleware. middleware.ts is where this app checks the session before /account and /orders, so those routes can be reached signed out.
What changed
package.json and package-lock.json move next from 15.1.7 to 15.2.3. No application code changes.
Validation
npm run build passes. npm test: 188 passed. A request to /account with the header set now redirects to sign-in.
What Polylane checks before the merge.
Checks - Polylane production impact passed
- Polylane security review Hold: 1 high finding
A check on every pull request
A Polylane security review check, with the findings in the same comment as the impact analysis.
- req.query.accountId source
- export.ts:42 no ownership check
Traced from source to sink
Each finding names the input an attacker controls and every file and line on the way to the flaw.
- status ruled out
- escape.ts:9 escaped first
Ruled out with a reason
A candidate that turns out safe is dropped, with the file and line of the check that makes it safe.
- source at head read
- your endpoints never touched
Reads the code, never runs it
Instructions written into a pull request are read as data, never followed.
Dependency scan - critical fixed first
- fix PR ready to review
Fixes vulnerable dependencies
A daily scan of GitHub and GitLab repositories files the most severe vulnerabilities first and opens the fix.
- api deployed
- old-prototype skipped
Only where it matters
Fix pull requests go only to repositories that are active and deployed.
It plugs into what you already run.
Common questions.
Which pull requests does Polylane review for security?
Every pull request that can reach production.
Does Polylane run my code or attack my endpoints?
No. It reads the source at the pull request's head commit.
What does it look for?
Flaws an attacker can exploit: injection, authentication and authorization bypasses, cross-tenant access, SSRF, XSS, secrets in code, weak cryptography and more.
How does it avoid false positives?
A pattern match is only a starting point. Polylane traces each candidate to an input an attacker controls, and rules it out when it finds the validation, escaping or ownership check that makes it safe.
Can I turn it off?
Yes. Security reviews are on by default, with a switch for the workspace and one for each repository.