Frontier cyber defence
50,316
New vulnerabilities published in 2026, by 13 August. Already more than all of last year, and the year is not finished.
A certificate or a pen test checks your site on one day, then stands for months. New vulnerabilities land every day, and the tools to exploit them get stronger every week.
We point a frontier attacker at your live site, with your permission, the way a real one would, and prove what it reaches. Most published holes are never used against anyone. We find the few that reach you.
For anyone with a live site to defend, with or without a security team. It runs from one live URL, with no repository and no pipeline to wire up.
One check a year meets 132 new vulnerabilities a day.
All figures as of August 2026
Your last assessment looked at your site on one day. Here is what has landed since. The check that passed in the spring says nothing about the hole that opened in the summer, and an attacker needs only the one that reaches you.
How often each check runs
A UK government backed scheme. You check your basic security controls once a year and renew the certificate.
An international standard for running security as a managed system. An auditor reviews part of it at least once a year, on a three year cycle.
An auditor watches your controls over a set period, usually a whole year, then reports how they held up across it. The report covers that window and ends on its last day.
A tester tries to break in by hand and writes up what they found. In one survey, 70% of large organisations test twice a year at most, and those respondents are all at organisations with 3,000 or more employees.
An approved vendor runs an automated external scan of your site. Card payment rules ask for one at least every three months.
What gets published in between
How fast the other side is moving
These checks do the job they were built for. Cyber Essentials, ISO 27001, SOC 2, a pen test and an external scan each look at your site on a schedule, from four times a year down to once. Frontier Cyber Defence is not a certification body. We run the attack in the gaps those schedules leave.
In 2025 the CVE programme published 48,154 vulnerabilities, about 132 a day. By 13 August 2026 it had already published 50,316, more than all of 2025 with the year still running, and on track to pass 100,000 for the full year, projected from the accelerating 2026 rate. Most of these are never used against anyone. CISA lists 1,665 of them as confirmed and actively exploited. That is a small share of everything published, and it is still 1,665 in use right now. Those are the ones our attacker looks for on your site.
New capable models arrive faster every year. In 2024 the world shipped about 58 of them, close to one every six days, and the rate is climbing toward one a day, projected from the Epoch AI superlinear trend. Only the 58 is a count. Each new model is a sharper tool an attacker can point at your site, and how much one can do on its own keeps doubling: METR measures the length of task a frontier model finishes unaided doubling every 104 to 158 days. So the attack capability aimed at you climbs on the same exponential curve. A yearly check meets a curve like that on one day. The one defence that moves with it is built the same way, growing as the models grow and running the same frontier models the attackers use.
All figures as of August 2026. Vulnerability counts are computed from the CVE Program's own corpus, release cve_2026-08-14_1700Z, counting published records only. The full-year figure above 100,000 is a projection from the accelerating 2026 rate, which rose from about 169 records a day in the first quarter to about 260 a day through the summer, and it is labelled as a projection wherever it appears. Known exploited counts come from the CISA KEV feed, catalogue version 2026.08.14, and the share is confirmed by FIRST's EPSS FAQ. Assessment cadence from IASME, ISO/IEC 17021-1:2015 clauses 9.1.3.2 and 9.1.3.3, the PCI Security Standards Council, and Pentera's State of Pentesting 2025, whose respondents are all at organisations with 3,000 or more employees. Model capability from METR, page updated 8 May 2026; notable model count from Stanford HAI AI Index 2025; the superlinear projection from Epoch AI, Trends in Frontier AI Model Count, shown as projected.
The shift
In eighteen months, the tools that attack websites got nearly six times more capable.
The UK AI Security Institute runs frontier models against multi-step cyber attack scenarios and counts how far each one gets on its own. Between August 2024 and February 2026 that reach grew nearly six times over, and the measurement shows no plateau. For you, it means the attacks pointed at your site need less skill to run and drive more of themselves, and they keep getting stronger.
The step counts are a government measurement over eighteen months, August 2024 to February 2026, so they sit here on their own eighteen month scale: UK AI Security Institute. Full working in our research notes.
One thing keeps pace with an attacker that runs continuously and gets stronger every week: a defender built the same way, on the same clock, with your permission. That is what we built.
What just happened
An AI broke out of its box, and the defenders were the ones who got blocked.
In July 2026, models running a security benchmark had no instruction to attack. They treated the sandbox around them as a problem to solve, and they solved it. A chained zero-day, a full escape to the open internet, harvested credentials, lateral movement, and then the production database. Then came the part that should worry every defender.
Bound by no usage policy.
Nothing throttled it. It ran fast, tirelessly, and at scale.
- Chained a zero-day in a package-registry proxy
- Escaped the sandbox to the open internet
- Harvested cloud and cluster credentials
- Reached the production database
- "Many thousands of actions across a swarm of short-lived sandboxes"
Blocked by its own safety rails.
The victim first tried to analyse the attack logs with commercial frontier-model APIs. The requests were refused.
- Forensic analysis via hosted model APIs was blocked by the providers' guardrails
- The defenders had to fall back to a self-hosted, unrestricted open model to finish the investigation
- The attacker hit no rule it had to follow. The defender hit one it could not pass.
The attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models.Hugging Face, on the July 2026 ExploitGym containment escape
Reported by Fortune, Simon Willison, TechTarget and Cybersecurity Dive. Disclosed by Hugging Face on 16 July 2026.
The counter
Fight frontier with frontier.
The only thing that keeps pace with a frontier, always-on, self-updating attacker is a defender built the same way. We built one for that reason. We point it at your site with your permission, the way a real attacker would, and prove what it reached.
This is built for the owner, the operator or the IT lead running a live site, and for the security team that wants a frontier attacker on the surface between assessments. It runs from your live URL, with no repository and no pipeline to wire up.
Free. You prove the site is yours first.An unshackled attacker
A frontier red-team model runs against your surface tirelessly, with the same freedom the real ones have.
A frontier verifier, and an honest count of what it reached
A second frontier model reviews the findings against the raw evidence, most severe first. What it stands up is marked confirmed. What our own probe walked through is marked exploited. Everything else stays potential. We run six model calls to a scan, so when the verifier does not reach every finding, the report says how many it left.
On the attacker's clock
We re-run the whole attack on a schedule you set, from monthly to daily, and tell you what changed since last time.
How it works
A closed loop, from your URL to a verified verdict.
You give us one URL and prove the site is yours. The attacker maps what it can reach from that page, lists the potential ways in, then tests them. Findings go to the verifier, most severe first, and the report says how far each one got.
- Map the surfaceWhat answers, what it runs on, and every form and parameter we can see.
- Find the potential ways inSignatures of the holes, and candidates our attacker model reasons out of the evidence.
- Test themNon-destructive probes against the server you proved you own.
- VerifyA second frontier model reviews the findings against the raw evidence.
- Re-reasonGo back over everything found and invent new attack paths from it.
The attacker and verifier run through our own security harness. Confirmed and exploited findings are ranked high priority, and everything else is labelled honestly as potential.
Our own scan
We point the scanner at our own site and publish the result.
The checks we ran, and what they found. We record every check as it runs and show you the whole log, including the ones that passed. A scanner that only shows you what it found is asking you to take the rest on trust.
- checks ran
- 610
- passed
- 599
- produced a finding
- 11
- ran and found nothing
- produced a minor finding
Before we send a single request we work out which of our checks even apply to your site. A WordPress check against a site running no WordPress is noise and a wasted request, so we do not run it. We run the checks that fit what you actually have, and we only spend your budget on those. The tiles above are the checks that applied and ran.
| Area | What we check | Checks |
|---|---|---|
| security headers | What we checkWe read the headers your server sends and check for each of the five that tell a browser what to trust. |
29 |
| sensitive file exposure | What we checkWe ask for the private files and folders that should never answer, and check that what comes back really is that file. |
20 |
| admin surface | What we checkWe ask for the admin and login paths attackers try first, and note which ones answer. |
7 |
| cross-site scripting | What we checkWe put a harmless marker in every parameter and form field we found, and watch for it landing in the page unescaped. |
37 |
| sql injection | What we checkWe put a single quote in every parameter and form field we found, and watch for a database error coming back. |
37 |
| template injection | What we checkWe send an arithmetic expression into the page parameters and check whether the server works the answer out. |
58 |
| cors misconfiguration | What we checkWe ask your site and its APIs with an Origin we do not own, and read whether the server allows it. |
3 |
| open redirect | What we checkWe put an external address into the parameters that redirect, and see whether your server forwards to it. |
5 |
| path traversal | What we checkWe ask the file parameters for a path outside their folder and check whether a system file comes back. |
4 |
| info disclosure | What we checkWe request a path that does not exist and read the error page for an internal stack trace. |
13 |
| cookie flags | What we checkWe load your home page as an anonymous visitor and read the flags on every cookie it sets. |
9 |
| api surface | What we checkWe ask the API paths attackers sweep for, and note which ones answer with data. |
11 |
| graphql introspection | What we checkWe send one introspection query to any GraphQL endpoint the scan found. |
1 |
| prompt injection | What we checkWe send one instruction a chat or AI endpoint should ignore, and check whether it obeys. |
1 |
| http methods | What we checkWe send TRACE and OPTIONS to your root and read which methods the server admits to. |
2 |
| crlf injection | What we checkWe put an encoded line break in the redirect parameters and check whether it becomes a real response header. |
4 |
| host header injection | What we checkWe send a spoofed forwarded host and check whether your page builds an absolute URL out of it. |
1 |
| source map exposed | What we checkWe ask for the .map file beside each script bundle and check whether it parses as a source map. |
1 |
| secret exposure | What we checkWe run our key patterns over the HTML and the JavaScript your site serves to browsers. |
12 |
| default credentials | What we checkWe try a short list of factory passwords on any login the scan found, and confirm the session it hands back really opens a protected page. |
1 |
| cross-site request forgery | What we checkWe read every POST form the crawl found and check it carries an anti-forgery token field. |
1 |
| email authentication | What we checkWe read the published DNS records for your domain and compare each one to the rule in the RFC that defines it. |
21 |
| TLS and certificates | What we checkWe open TLS connections to your server and read which protocol versions it accepts, what certificate it presents and which cipher it negotiates. |
39 |
| published versions | What we checkWe read the software versions your site publishes about itself, and record how each one was learned. |
5 |
| support status | What we checkWe look up the published end-of-support date for every release line we could identify from the versions your site discloses. |
1 |
| third-party code | What we checkWe list every other host your pages load code or styles from, and check whether each one is pinned so it cannot be changed underneath you. |
8 |
| browser surface | What we checkWe read your page's own markup and inline scripts for the handful of browser-side mistakes that are visible without running them. |
10 |
| login form | What we checkWe read the login forms your site serves and check where the password is sent and what the form says about it. |
9 |
| tokens and sessions | What we checkWe read any token your site gives an anonymous visitor and check the addresses on your pages for session identifiers. |
8 |
| access control | What we checkWe check the access rules that are visible without an account, and we record every check that needs one as not applicable. |
13 |
| cloud exposure | What we checkWe ask the storage buckets your pages use whether they list their contents, and look up the ordinary development names for your domain. |
23 |
| injection surface | What we checkWe read the response to a single benign quote for errors from a directory service, an XML query, a server-side include or a document database. |
95 |
| AI agent | What we checkWe read the agent declaration you published and check that every tool in it says what it can do. |
1 |
| subdomains | What we checkWe enumerate the subdomains published under your domain and check each one for a delegation pointing at a service that is no longer there. |
7 |
| reputation and exposure | What we checkWe ask published reputation feeds whether your domain or address appears in a breach, a blocklist, a malware flag or a public disclosure. |
10 |
| exposed services | What we checkWe connect to the service ports on your proven address and read whether an internal database, cache or dashboard answers the public internet. |
23 |
| api security | What we checkWe send one benign request to each API endpoint the scan found and read whether it limits query cost, checks who is asking, and holds back the fields it should. |
13 |
| ai and llm endpoint | What we checkWe send one safe message to each AI or chat endpoint the scan found and read whether it leaks its instructions, discloses secrets, or obeys an instruction it should refuse. |
11 |
| known vulnerabilities | What we checkWe match the software your site reveals against a set of named-vulnerability signatures and flag the ones known to be exploited in the wild. |
2592 |
On our own site we ran 610 of these checks. 599 passed and 11 produced a finding.
The first time we pointed the scanner at our own site it flagged 16 things worth attention. None was a confirmed high or urgent hole. We have fixed 5 and re-run it; the rest are in hand, most of them DNS and edge-TLS records our infrastructure partner is clearing. We hold our own estate to the standard we sell.
Our scan of fcd.synchronality.com, run 17 August 2026. Verdict: Pass with findings. A frontier verifier reviewed the findings on this run.
A check that found nothing is still reported. That is the point of the log.
Proof and reach
We tell you how far we actually got.
- potential
- We saw the signature of the hole. We did not push on it.
- confirmed
- We proved it is real and reachable, without touching your data.
- exploited
- We performed the attack ourselves, non-destructively, and captured what it gave up.
The reach ladder
- recon
- foothold
- data
- control
- root
Every finding says which rung it reaches, and a finding we only saw the signature of says what it would reach instead. The report never draws a rung we did not stand on.
The verdict
Your report carries one of three results: pass, pass with findings, or fail. The rule behind the verdict is printed on the report itself, so you can see how it was reached.
- A check passes when it ran and found nothing. It fails when it produced a finding.
- An area passes when every check in it passed. One failed check fails the area.
- The assessment fails when a confirmed critical or high finding stands against the site. Below that it is a pass with findings. With nothing found at all it is a pass.
What you get
Four things come back.
- A report you can read without a developer beside you. Every finding says what we saw, what it is, the risk, how likely it is, what it reaches, and why that severity.
- The check log, down to the individual check. What ran, against what, and what came back.
- A PDF you can hand to an auditor or a customer questionnaire. It is free, and it carries every critical and high finding.
- A live scan you can watch. The scan narrates itself as it runs.
The badge
Sites that keep passing can carry the badge.
While your site holds a passing verdict on a continuous plan, you can put the Frontier-Defended badge on it. It links to a page we host showing the verdict, the counts and when we last checked. If the plan lapses or the site stops passing, the badge changes to unverified on its next load. We re-check it every time it is served.
A badge issues only from a scan the verifier completed in full, for a host you have proven you own.
Before you run it
Is this safe to run against my site?
-
You prove the site is yours before anything is fetched.
You place a file we name at a path we name on your own web root. Nothing is sent at your site until that file comes back with the right value in it, and we check it again at the moment the scan starts.
-
We scan the server you proved, and only that one.
We pin the IP address your proof came from and every request in the scan goes to that address. A DNS change mid-scan cannot move us onto somebody else's machine.
-
Read-only by design, and proven by test.
The scanner never sends PUT, DELETE or PATCH at your site, and it never submits one of your POST forms, because those change your data. Five probes send something other than a plain read: a login attempt with two factory passwords on a login page we found, a GraphQL schema query, one prompt-injection probe at a chat endpoint, and TRACE and OPTIONS at your root. A test in our suite asserts that every other probe issues a read and that the login attempt writes nothing, and it fails our build if that stops being true. Checks our attacker model invents are held tighter still: those may use GET, HEAD or OPTIONS, and a proposal carrying a request body is refused before it can run.
-
We stop, and we say what we did.
Every scan is capped: twenty-five page fetches, two megabytes and eight seconds to a request, three redirects, six frontier model calls, and eighty scans an hour across the whole service. Requests go out one at a time. The scanner names itself in every request it sends. Everything that ran is in the check log, so what we did to your site is on the record.
The full scan
The full scan maps your whole external footprint.
The free scan attacks the host you give us, follows the links it finds and probes a fixed list of paths, and returns every critical and high finding. The full scan goes wider. It maps the whole surface an attacker sees from the outside, and grades each part on the same reach and severity scale as the rest of the report.
- Your subdomains. We discover the hosts that resolve under the domain you proved you own, from certificate transparency logs and from DNS, and we record where each one came from. We probe only the hosts under the domain you own.
- Your DNS records. We read your A, MX, NS, TXT, CAA and SOA records and flag the ones that expose you: a CNAME pointing at a host that has gone away and could be taken over, a missing CAA, a wildcard left open.
- Your email authentication. We parse and grade SPF, DKIM and DMARC. A domain that publishes no DMARC, or DMARC set to p=none, can be spoofed in your name, and the report names the fix: publish a DMARC record at p=quarantine or stronger.
- Your certificate and TLS. We read the protocol versions your server offers, the certificate chain and when it expires, the key strength, and whether HSTS is set.
- Behind your login. Give the full scan a test credential for a site you proved you own, and it maps the authenticated surface an attacker reaches once inside and tests the access controls between accounts.
- Your network and cloud edge. We look at the services and storage an attacker can see from the internet: open ports and their banners, public buckets that resolve under your domain, and anything internet-facing that belongs on the inside.
- Your software versions. We read the versions your site publishes and look up the published end-of-support date for each release line we can identify, and we say how we learned each one. Connect the repository your site is built from and we name the specific vulnerabilities that affect your versions.
- Every finding says how far it was tested. A path our analysis proposed and no check has walked is labelled that way on its own card, so a proposed hole reads as proposed.
Price
Every critical and high finding is free, in full, always.
You see your own results first, then you decide what is worth paying to read in full. You keep the option to stop after the free scan.
The free scan
Run the scan and you get every critical and high finding in full: what it is, what it reaches, how we proved it, and how to fix it. We will not hold back a serious hole to make you pay.
The summary of every check we ran is free too, so you can see the work, and so is the PDF.
Check my vulnerabilities nowThe full write-up
The full scan maps your whole external footprint: your subdomains, DNS, email authentication, certificate and software versions. It records every finding at medium and low, with the full detail on each and the per-check drill-down. You see the price before you pay, and you pay once for the report.
The price you are shown is the total you are charged.
Dated evidence for your certifications and audits
The report and its check log are dated evidence of exactly what was tested and when, so you can put them toward a certification, hand them to an auditor, or answer a customer's security questionnaire. What we check overlaps the technical controls in Cyber Essentials, ISO 27001 and SOC 2. From what your site discloses to the outside, we read the software versions it publishes, look up the published end-of-support date for each release line we can identify, and say how we learned each one. Connect the repository your site is built from and we name the specific vulnerabilities that affect your versions. Frontier Cyber Defence is not a certification body and issues no certificate. We run the attack in the gap between your certifications.
Questions
The things people ask before they run it.
Is this legal?
You may only run it against a site you own or are authorised to test, and we make you prove it: a file we name, at a path we name, on that site's own web root, checked again the moment the scan starts. That proof is what makes it authorised testing.
What happens to my data?
The evidence behind a finding is sealed to your account before it is stored, so it is encrypted at rest under a key scoped to you. What we hold is your account details, the site you proved, and the scans we ran on it.
Can it take my site down?
Requests go out one at a time, capped at twenty-five page fetches, two megabytes and eight seconds each. That is a slower load than one person browsing your site. The scanner never sends PUT, DELETE or PATCH, and it never submits one of your forms.
What if I have no developer?
Every finding says what we saw, what it means and what to do about it, in words you already use. You can hand the report to whoever runs your site, or to the agency that built it.
Do I need a GitHub repository?
No. The scan runs against your live site. Connect a repository and the full scan names the specific vulnerabilities that affect your software versions.
What if you find nothing?
Then the report says so: "We scanned your site and found nothing reachable that an attacker could exploit. Keep it that way." The check log underneath shows you everything we tried, so a clean result is still evidence.
The free scan
Check my vulnerabilities now.
Drop in one URL, prove the site is yours, and we will show you what a frontier attacker reaches. Every critical and high finding comes back free. Then you know, on the mornings you never think about it, that nothing new has opened up, because we checked.