Atlassian warns of critical file access flaw in its datacenter products
As AI models become more capable, they uncover more security vulnerabilities and identify increasingly sophisticated paths to exploit them, raising the bar for how quickly defenders must respond. Security teams now face more potential vulnerabilities than their existing processes were designed to handle โ each requiring investigation, reproduction, and a repair that must be tested to confirm it closes the vulnerability without breaking expected behavior.
AWS Continuum for code vulnerabilities accelerates this work with autonomous security at machine speed. To measure Continuum against a concrete public standard, we chose CyberGym-E2E, which asks an agent to find a vulnerability in a real codebase, demonstrate it with a working proof of concept, and repair it without breaking behavior covered by the projectโs tests. Continuum passed 819 of 920 tasks within the benchmarkโs 90-minute limit, achieving an 89.0% end-to-end success rate. This establishes a new standard 23.1 percentage points up from the previous public high of 65.9%.
Many security benchmarks test a single task in isolation. Detection benchmarks test whether a system can identify suspicious code, while patching benchmarks begin with a known flaw and ask for a fix. CyberGym, the predecessor to CyberGym-E2E, also begins with a known vulnerability and focuses on exploit generation. By contrast, CyberGym-E2E evaluates the full vulnerability lifecycle, requiring a system to identify and demonstrate a vulnerability before producing a tested repair. This broader scope more closely reflects the work facing security teams.
Each CyberGym-E2E task places an agent in a container with a vulnerable revision of a real open-source project and the tools needed to build and test it. An agent can inspect and modify the source, but receives no vulnerability description, proof of concept, crash log, or original patch. External network access is blocked, and protected benchmark files cannot be modified. Within 90 minutes, the agent must submit an input demonstrating a vulnerability and a source-code patch. The full benchmark contains 920 tasks based on historical OSS-Fuzz vulnerabilities across 139 open-source projects. The median project contains more than 600,000 lines of code.
The benchmark evaluates each submission in four cumulative stages:
CyberGym-E2E defines S3 as its main measure of end-to-end success. S4 is diagnostic because a repository may contain several valid vulnerabilities: an agent can find and repair a real flaw that differs from the benchmarkโs selected target.
Continuum for code vulnerabilities reached a new standard for every stage of CyberGym-E2E. The table below compares its performance with the previous best public results.
| Stage |
What it measures |
Continuum |
Previous public high |
Difference |
| S1 |
Finds and reproduces a vulnerability |
92.5% |
67.9% |
+24.6% |
| S2 |
Repairs its generated crash |
89.6% |
66.2% |
+23.4% |
| S3 |
Preserves tested functionality |
89.0% |
65.9% |
+23.1% |
| S4 |
Also repairs the benchmarkโs selected vulnerability |
37.8% |
26.2% |
+11.6% |
On S3, the benchmarkโs main measure of end-to-end success, Continuum passed 819 of 920 tasks. Its 89.0% success rate exceeds the previous public high of 65.9% by 23.1 percentage points. The result reflects both the capability of the underlying frontier models and Continuumโs design as a multi-agent security system. The next section examines how that system adds value beyond the models alone.
The official 89.0% result applies CyberGym-E2Eโs 90-minute limit. When tasks were allowed to continue beyond that limit, Continuumโs end-to-end pass rate reached 93.7%, indicating higher potential coverage when longer-running analyses can complete.
We conducted the evaluation under CyberGym-E2Eโs network-isolation and submission-review requirements. External retrieval was blocked during execution, and post-run trajectory review confirmed that successful results came from vulnerability analysis rather than retrieval of public historical fixes.
Continuum for code vulnerabilities is a multi-agent system organized around the main phases of the code vulnerability lifecycle: discovery, validation, and remediation. Each phase uses specialized agents adapted to the evidence and decisions it requires. The system carries evidence forward so that each phase builds on the work completed before it.
During discovery, Continuum analyzes the repository and develops candidate vulnerability findings. Its agents identify code paths that warrant deeper investigation and record the source evidence supporting each candidate.
During validation, specialized agents attempt to turn a candidate finding into a demonstrated security issue. They construct a proof of concept, run it against the vulnerable program, and determine whether the observed behavior supports the finding. This converts a potential code-level weakness into executable evidence.
During remediation, agents trace the vulnerability to its root cause and produce a patch. Continuum then verifies that the patch prevents the demonstrated failure and that the projectโs functionality tests continue to pass. The repair is therefore evaluated against the same evidence used to establish the vulnerability.
Together, these phases create a connected record from suspicious code to a demonstrated vulnerability and tested repair. The architecture allows Continuum to adapt its tools, instructions, checks, and models to each phase while maintaining a consistent standard of evidence. It also supports a multi-model approach that can leverage complementary strengths and incorporate new models as they become available.
In customer environments, Continuum can also combine code-level evidence with available deployment context, including service exposure, network paths, permissions, and configuration. This context helps distinguish vulnerabilities with limited production impact from exposures that demand immediate action. CyberGym-E2E evaluates the code-level process but does not provide deployment context, placing this broader prioritization capability outside the benchmarkโs scope.
CyberGym-E2E advances security evaluation by turning a complex, multi-stage process into a large public benchmark with reproducible tasks and outcomes that can be verified by running code. The CyberGym-E2E authorsโ careful work on task construction, scoring, and submission standards gives the field a concrete foundation for measuring end-to-end progress.
To keep evaluation consistent and reproducible across 920 tasks, CyberGym-E2E focuses on memory-safety vulnerabilities in C and C++ projects. Sanitizer-detected crashes provide objective evidence of a defect, while subsequent checks determine whether a repair blocks the proof of concept and preserves functionality covered by the projectโs tests. This design necessarily leaves many languages and vulnerability classes outside the benchmarkโs current scope, including many of the most common and impactful bug classes observed in production systems. Evaluating these areas will require different task environments and equally rigorous forms of validation.
Our view of end-to-end security also extends beyond producing a tested code-level repair. In production systems, deployment context such as service exposure, network paths, permissions, and configuration often determines whether a vulnerability presents limited risk or demands immediate action. Future evaluations should test whether autonomous systems can reason about this context and prioritize findings according to their effect on the safety of the deployed system.
CyberGym-E2Eโs value extends beyond the dataset itself. It makes the case that end-to-end security is worth defining and measuring as a task in its own right. That involves hard design choices about scope, evidence, and what counts as success, and CyberGym-E2E gives the field a concrete starting point for working through those choices. This system-level view complements our work on the Deception Benchmark, which evaluates a narrower but related capability: how reliably individual frontier models distinguish real vulnerabilities from safe code. Together, they examine security performance at both the model and system levels.
To learn how AWS Continuum for code vulnerabilities helps teams discover, validate, prioritize, and remediate vulnerabilities at machine speed, visit the AWS Continuum product page.
Somewhere in your organization is a spreadsheet of certificate expiry dates, and someone who owns it. That is not a caricature. DigiCertโs 2026 research with Omdia surveyed more than 400 senior IT leaders and found that 47% still rely on manual tracking methods such as spreadsheets, and only 34% have a complete, current view of what they hold. The spreadsheet works because renewals come around once a year, and one person with a calendar can keep the whole estate in their head.
The industry has decided to take that away. The CA/Browser Forum voted in April 2025 to bring the maximum TLS certificate lifespan down in steps: 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029, with domain validation reuse dropping to 10 days. The first step is already live: since March 15, 2026, no publicly trusted TLS certificate can be valid for more than 200 days. By 2029 you will be proving ownership of your domains roughly every month, for every certificate, forever. The spreadsheet does not survive that. Neither does the person.
Shorter lifespans shrink the window in which a stolen key or a mis-issued certificate is useful, and they push the whole ecosystem onto automation, which is where the reliability actually comes from. The destination is better. The journey is where outages live. Every manual step in your renewal process is a place where a 47-day cycle breaks something a 365-day cycle never stressed. We covered what the vote means for Imperva customers when it passed; this post is the checklist.
hasSNI == false, set to Alert, logs every non-SNI request as a security event without blocking anything. Leave it running for a week or two, since some of this traffic is periodic, then decide. Imperva Cloud WAF Technical Guide: How to Identify Non-SNI Traffic Before Enabling SNI-Only Mode walks through it step by step.Imperva-managed certificates have already moved to 90-day validity (with domain validation every 99 days), ahead of the industry deadlines, with renewal and deployment automated end to end. Root trust is moving too: the GlobalSign root transition (R3 to R46) is covered by a cross certificate that Imperva includes by default until the R3 root expires in March 2029, so legacy clients keep working, and action is needed only if you pin to a specific root certificate. The direction of travel is simple. Certificate work becomes something you configure once, not something you do monthly.
The detail lives in the Cloud WAF documentation, and walks the site-certificate path step by step.
Back to that spreadsheet. If it is yours, the right time to retire it is while it still works. If you retired it years ago, the question is whether your automation reaches all the way to your applications, or stops at the CA.
When do 47-day TLS certificates take effect?
From March 15, 2029, publicly trusted TLS certificates can be valid for no more than 47 days. The CA/Browser Forum schedule gets there in steps: 200 days from March 15, 2026 (already in force) and 100 days from March 15, 2027.
How often will I need to validate domain ownership?
The period for reusing domain validation follows the same schedule: 200 days from March 2026, 100 days from March 2027 and 10 days from March 2029. In practice that means validating for almost every renewal, which is why an automated method such as CNAME delegation matters.
Do I need to do anything for Imperva-managed certificates?
Imperva renews and deploys its managed certificates automatically, and they already have 90-day validity. What stays with you is domain validation (automatic CNAME validation removes it), moving SNI sites from shared account certificates to site certificates, and updating your trust store if you pin to a root certificate.
What happens to clients that donโt support SNI?
A client that doesnโt send SNI canโt be served a site certificate, and once a site moves to SNI-only mode those connections are rejected. A custom rule with the filter hasSNI == false, set to Alert, shows whether you have any before you switch.
The post 47-Day Certificates Are Coming: Five Things to Do Before They Arrive appeared first on Blog.


Somewhere, an attacker is recording your encrypted traffic. Not breaking it. Recording it. The bet is patient and simple: store ciphertext today, wait for quantum computers to mature, decrypt at leisure. The industry calls it harvest now, decrypt later (HNDL), and it is the rare security threat with a believable deadline attached: data with a ten-year shelf life, encrypted with algorithms on a countdown.
Most quantum-readiness advice hands you a project: audit your cryptography, plan your migration, stand up a working group. Here is what Cloud WAF customers had to do to get quantum-safe TLS on every connection between their users and the Imperva network: nothing.
Every TLS 1.3 connection from a PQC-capable client to Imperva now negotiates hybrid TLS key agreement: X25519MLKEM768, which runs classical X25519 and quantum-safe ML-KEM-768 together. ML-KEM is the key-encapsulation mechanism NIST standardized as FIPS 203 in August 2024. It is enabled by default on all Imperva sites, with zero configuration and no measurable performance trade-off. If a client supports it, it is on. Your usersโ sessions are already protected against the recording attack, and nobody on your team filed a ticket to make that happen. You can see it for yourself: open Chrome DevTools, go to the Security panel, and the connection to any Imperva-protected site lists X25519MLKEM768 as its key exchange. We explained earlier this year why post-quantum cryptography canโt wait; this post is the update now that both legs are covered.
A proxy architecture has two connections per request: client to edge, and edge to origin. As of the October 4, 2026 release, Imperva also supports PQC on the Imperva-to-origin leg, so customers whose origin servers support post-quantum key agreement get quantum-safe encryption end to end: from the userโs browser, through the Imperva network, to their own infrastructure. The requirement on your side is one sentence long: an origin that can negotiate the hybrid handshake. In practice, that means OpenSSL 3.5 or later, which offers X25519MLKEM768 by default. Sites created on or after October 4, 2026 get PQC to origin automatically. Existing sites keep their current behavior until you switch it on under SSL/TLS Configuration > Origin connection security, or with the /v3/sites/origin-pqc API. If an origin canโt negotiate the hybrid handshake, the connection falls back to classical TLS without disruption.
Post-quantum TLS is arriving across the industry, and that is a good thing; no vendor should claim the category. What differs is the operational bill. Here the answer is: defaults. No premium SKU, no per-site enablement, no migration project for the edge leg, and, for end to end, an origin-side capability check plus one switch on sites created before October 4, 2026. For regulated sectors already fielding quantum questions from auditors and boards (finance, healthcare, defense), that turns a program into a paragraph in your next review. Behind it sits the Thales portfolio, where post-quantum work spans well beyond the WAF. One limit worth stating plainly: hybrid key agreement protects the confidentiality of each session, which is exactly what a harvest now, decrypt later attack targets. Certificate signatures are a separate, later migration (NISTโs ML-DSA, FIPS 204), because forging a signature needs a quantum computer at the moment of the handshake. Recorded traffic gives an attacker nothing to work with there.
Detail, including how to test PQC and how to switch it on for your origin, is in the Post-Quantum Cryptography (PQC) Support documentation.
The recording attacker is patient. As of now, what they are recording from your traffic is noise with no future.
An attacker records encrypted traffic today and stores it until a cryptographically relevant quantum computer can break the classical key exchange that protected it. Data that must stay confidential for years is at risk now, even though that quantum computer does not exist yet.
Yes, for the key exchange. TLS 1.3 connections from PQC-capable clients to Imperva use hybrid X25519MLKEM768 by default on all sites. Connections from Imperva to your origin use it when the origin supports it (OpenSSL 3.5 or later) and PQC to origin is on: by default for sites created on or after October 4, 2026, and opt-in for existing sites.
It is the hybrid TLS 1.3 key-exchange group that combines classical X25519 elliptic-curve key agreement with ML-KEM-768 (FIPS 203). An attacker has to break both to recover the session key. It follows the hybrid model adopted by Google Chrome and other major browsers, and it is what Chrome DevTools shows when a connection is post-quantum protected.
The connection falls back to classical TLS key exchange without disruption. PQC is used only when both sides support it, and it requires TLS 1.3. See the Imperva PQC documentation for the handshake scenarios.
The post Harvest Now, Decrypt Later: The Attack You Defend Against by Doing Nothing appeared first on Blog.
