❌

Reading view

Atlassian warns of critical file access flaw in its datacenter products

Atlassian has told its users to patch its datacenter products, pronto, to prevent attackers accessing their files. The Australian collaborationware company on Monday sent users an email that opens with the words “Action required” and points to a security bulletin that explains CVE-2026-21589. The 9.3-rated arbitrary file access vulnerability is present in the datacenter versions of its Bitbucket, Confluence, Jira Service Management, Jira Software, Bamboo, Crowd, Crucible, and Fisheye products. Atlassian says the vulnerability “allows an unauthenticated attacker to access specific files within the web application root directory in affected versions.” That’s scary because Atlassian warns “In some configurations, there may be sensitive files present that increase your risk.” There’s also some good news in that attackers must know the exact filename and path to exploit the vulnerability, and the mess doesn’t allow anyone to see the contents of a directory. Another piece of good news is that Atlassian has updated its products – so users only need to find a change window in which to upgrade to a safe version of their software. Atlassian advised those who can’t patch ASAP to remove their instances from the internet, if possible. “Instances accessible to the public internet, including those with user authentication, should be restricted from external network access until you can take action,” the company warned. Its advisory also includes mitigations and advice on how to determine if your instances need the fix. Users who made the move from datacenter products to the Atlassian cloud have nothing to do, as Atlassian fixed the flaws in its own SaaS. That state of affairs rather vindicates Atlassian’s 2020 decision to stop developing its low-end server products and require users to shift into its cloud, and last year’s sequel in which it decided to discontinue its datacenter software, too. Atlassian admitted it hasn’t made that migration easy, because it somehow released a lift and shift tool that was worse than an earlier version. In March 2026, Atlassian axed ten percent of staff. The company’s share price was on a year-long slide at the time, as pundits suggested it might fall victim to the SaaSPocalypse, a theory that AI would replace business software. The price of Atlassian scrip has tripled since then, suggesting investors are more confident the company’s plan to use AI to power workflows represents a moat LLMs cannot cross. ®

  •  

AWS Continuum sets a new standard in autonomous code security

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%.

Measuring the full vulnerability lifecycle

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:

  1. S1 checks whether the agent produced an input that crashes the vulnerable program.
  2. S2 checks whether the agent’s patch prevents that crash.
  3. S3 checks whether the patched project still passes its functionality tests.
  4. S4 checks whether the patch also fixes the specific historical vulnerability selected by the benchmark.

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 sets a new standard

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.

Harness design for end-to-end security

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.

Beyond CyberGym-E2E

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.


Alexander Greaves

Alexander Greaves-Tunnell

Alec is a scientist working on the design and evaluation of AWS Continuum for code vulnerabilities. At AWS, he has led projects across search, security, and observability that bring the AI state-of-the-art to complex application domains beyond the expertise of existing models. His academic background is in statistics.

Neha Rungta

Neha Rungta

Neha is a scientist and builder who has spent her career making machines reason about complex systems at scale. Her work spans automated reasoning, formal verification, security, and AI, shaping systems including Cedar, IAM Access Analyzer, and Continuum. Today, she is forging the next generation of machine reasoning, combining LLMs, formal methods, and agentic systems.

  •  

Citrix NetScaler security snafus get even worse amid more 0-day reports

The attackers just keep coming after Citrix NetScaler appliances, as both the feds and private security researchers warn that someone found - and has already exploited - yet another Citrix bug before it had a patch. This latest vulnerability, tracked as CVE-2026-88779, is a memory overflow bug that leads to denial of service attacks. It only affects NetScaler ADC and Gateway appliances configured as a SAML (Security Assertion Markup Language) service provider or identity provider, used for single sign-on authentication. Late Friday, amid exploitation reports, Citrix confirmed that it was investigating a “newly observed issue related to SAML authentication in customer-managed NetScaler deployments.” By Saturday night, the vendor released a security advisory for NetScaler ADC and NetScaler Gateway with patches, urging vulnerable customers to “install the relevant updated versions as soon as possible.” Citrix also posted a blog about the vulnerability, confirming that it has observed targeted attacks on unmitigated NetScaler deployments that can lead to denial of service. Citrix did not answer our questions about CVE-2026-88779 - including how many instances have been affected and what attackers are doing after exploiting the bug - but urged customers to "quickly apply" the fix to NetScaler instances. "We were recently alerted to a new issue that affects service availability for some NetScaler deployments," a Citrix spokesperson told The Register. "After we were alerted to this issue we immediately developed and published a mitigation while concurrently developing, testing and deploying a fix." On Sunday, the US Cybersecurity and Infrastructure Security Agency (CISA) confirmed CVE-2026-88779 was under active exploitation and ordered federal agencies to patch the bug by Wednesday. While the new vulnerability is not technically related to the earlier eight CVEs finally disclosed by Citrix on September 27 - weeks after miscreants began abusing two of these security holes (CVE-2026-88772 and CVE-2026-88771) - watchTowr researchers told us they suspect it has been used to purposefully crash machines, making exploitation of CVE-2026-88771 faster. “This vulnerability is incredibly simple to trigger, with a single specially crafted request being all that is needed to knock an appliance offline,” watchTowr’s head of threat intelligence, Jake Knott, told The Register. “Exploitation is already occurring in the wild, and disrupting an authentication gateway can prevent legitimate users from accessing the services behind it.” WatchTowr reproduced the vulnerability on Friday, and Citrix credited the attack-surface management company along with Bishop Fox with helping it address the issue. “Citrix provides an indicator-of-compromise script that teams can run to check exposed appliances for signs of compromise, though a clean result is not definitive proof,” Knott said. “Security teams should prioritize appliances configured as a Gateway or AAA virtual server with SAML authentication enabled, and affected organizations should apply the fixed build or Citrix’s interim mitigation if an immediate upgrade is not possible.”®

  •  

FBI confirms 'multiple' arrests related to ShinyHunters hack

The FBI and law enforcement partners have arrested “multiple” suspects as part of an investigation into a September hack allegedly involving data-theft-and-extortion group ShinyHunters, the bureau told The Register. “The bureau continues to aggressively investigate the recent cyber incident allegedly involving ShinyHunters, having already worked with partners to arrest multiple subjects and we will spare no resource in bringing each of the responsible individuals to justice,” an FBI spokesperson told us in an email on Monday. The FBI declined to comment on the specific arrests, including that of Saif al-Din Khader, a suspected ShinyHunters member who has reportedly been detained in Jordan, according to Reuters. Khader, who goes by the alias Rey, was reportedly brought into custody on September 29, and is said to be cooperating with the FBI to identify other members of the group. ShinyHunters did not respond to The Register’s inquiries about the arrest and Khader’s alleged involvement with the criminal group. Rey confirmed his real identity - Khader - to security journalist Brian Krebs last year. Krebs described Khader as the “technical operator and public face” of Scattered LAPSUS$ Hunters. “Rey got picked up finally,” said security sleuth Kevin Beaumont following news of the arrest. According to Beaumont, Rey was “one of the kids who got into JLR.” The Jaguar Land Rover (JLR) breach, which occurred in late August 2025, affected the company's IT systems and halted manufacturing operations. Dealer systems also went down, and suppliers faced canceled or delayed orders. In addition to crippling the carmaker’s business operations for months, the digital thieves stole personal payroll data belonging to thousands of JLR employees. The cyberattack, one of the most costly in UK history, was attributed to Scattered LAPSUS$ Hunters. Khader’s detention came two weeks after the Dutch National Police arrested a 24-year-old whom the FBI described as “one of the alleged leaders of ShinyHunters.” While Dutch cops have not named the suspect, Krebs and other reports say he is Pepijn van der Stap, who was convicted in 2023 for hacking and extorting numerous organizations and was on supervised release after three years in prison. Van der Stap also worked as a software engineer at the Amsterdam-based cybersecurity startup Hadrian and volunteered as a security researcher at the Dutch Institute for Vulnerability Disclosure (DIVD). In a video message following the arrest, Brett Leatherman, assistant director of the FBI's Cyber Division, had some advice for the “remaining members” of the data theft and extortion gang. “Arrests have a way of changing who is willing to talk, and seized infrastructure has a way of showing us who's left,” Leatherman said last week. “The longer you stay in this, the more we learn about you. You know how to find us, and we know how to find you. I suggest you reach out first while the choice is still yours.” At the time, the FBI declined to answer The Register’s questions about the video message, including whether it had seized any of the cybercrime group’s infrastructure, and whether any of ShinyHunters’ members had taken Leatherman up on his offer to “reach out first.” In late September, ShinyHunters hacked the FBIJobs.gov portal and claimed it stole sensitive personal details about current, former, and prospective FBI employees. A spokesperson told The Register that unlike most of its digital break-ins, this one was “NOT financially motivated … We want the FBI to correct or retract their statements they made, which included substantial false allegations.” Later, in an exclusive interview, the spokesperson told us the attention-grabbing hack was “fundamentally a public relations and marketing initiative for our business.” ®

  •  

47-Day Certificates Are Coming: Five Things to Do Before They Arrive

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.

Why TLS certificate lifespans are shrinking to 47 days

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.

How to prepare for 47-day certificates: five things to do, in order

  1. Inventory what you actually have. Every certificate, every domain, every site, and who renews it. Cloud WAF reports SSL coverage status for each protected site, so start with your public-facing estate. It is the part with a deadline attached and the part your customers meet first.
  2. Automate domain validation now. Manual validation at a 10-day reuse window is not a process, it is a permanent job for somebody. Automatic CNAME validation makes ownership proof continuous, and it is the single change that turns the 2029 schedule from alarming to routine. The payoff starts now, not in 2029: Imperva already requires domain revalidation every 99 days for its managed certificates. We walked through the setup in Effortless certificate management with automated CNAME validation.
  3. Find your non-SNI traffic before it finds you. Server Name Indication (SNI) is the TLS extension that tells the server which hostname a client is asking for. Clients that do not send it, usually older HTTP libraries, outdated monitoring tools and misconfigured internal services, cannot be served a site certificate (a site with non-SNI connections is not eligible for one), and they are rejected outright once a site moves to SNI-only mode. That is why this step comes before the next one. Non-SNI clients are also invisible unless you go looking. One custom rule with the filter 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.
  4. Isolate the blast radius. A certificate shared across your whole estate means one renewal problem is everyone’s problem. Imperva site certificates give each site its own certificate, its own coverage status and up to 50 domains, so one team’s missed renewal does not become another team’s outage. New SNI-only sites have required site certificates since September 13, 2026, and Imperva recommends migrating existing SNI sites off shared account certificates by December 31, 2026, before automatic migration begins in Q1 2027.
  5. Connect the certificate system you already run. If your certificates are governed in a Certificate Lifecycle Management (CLM) platform, the system that issues, tracks and renews certificates centrally, or in your own PKI, those renewals should reach your WAF without a person in between. The SSL Integration Center connects that workflow directly to Imperva Cloud WAF. DigiCert Trust Lifecycle Manager and Keyfactor Command are on the supported vendor list, with further CLM integrations in progress.

What Imperva is already doing: 90-day certificates and the R46 root

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.

Frequently asked questions about 47-day certificates

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.

  •  

Harvest Now, Decrypt Later: The Attack You Defend Against by Doing Nothing

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.

What shipped: hybrid post-quantum TLS on every Cloud WAF site

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.

The second leg: post-quantum TLS from Imperva to your origin

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.

The honest scope: what hybrid key agreement covers

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.

What to do about harvest now, decrypt later

  • Nothing, for the client leg. It is already on.
  • Check your origin stack for hybrid key-agreement support, and switch on the second leg when it does. That means OpenSSL 3.5 or later. New sites have PQC to origin on by default; existing sites need it switched on once, in the Cloud Security Console or through the API.
  • Put one line in your next security review: sessions through Cloud WAF are quantum-safe by default. Boards like sentences that end.

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.

Harvest now, decrypt later: FAQ

What is a harvest now, decrypt later (HNDL) attack?

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.

Is Imperva Cloud WAF traffic protected against harvest now, decrypt later?

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.

What is X25519MLKEM768?

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.

What happens if a client or origin doesn’t support post-quantum TLS?

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.

  •  

Legacy sign-on service comes back to bite school software provider Bromcom

UK education software provider Bromcom has notified customers of a personal data breach affecting its single sign-on (SSO) technology. In a September 24 EduGeek post, an account named Bromcom_Alastair said an unauthorized third party had accessed and retrieved email addresses and limited information associated with affected SSO registrations. The incident involved legacy SSO registration functionality in Bromcom's Communication Server environment. The company confirmed in an FAQ it found no evidence that its school Management Information System (MIS), used to manage student data, attendance, behaviour, and administration, was compromised. Bromcom said it was working with external forensic specialists to determine the nature and scope of the data involved. The company identified the incident on September 6 after reports of SSO access problems and has since withdrawn the legacy functionality from production. The service held email addresses associated with SSO registrations, the provider used, such as Microsoft or Google, registration and last sign-in dates where recorded, and internal user and registration reference numbers. Bromcom said the affected component did not hold account passwords or authentication tokens. The legacy SSO registration functionality had remained in production after being superseded because "it was still being called by an internal system," the supplier said. The incident did not enable access to Microsoft or Google accounts, whose authentication services are separate from the affected component said Bromcom. The Register has asked Bromcom to comment further. Bromcom provides information management software used in schools and the wider education sector in the UK. It offers tools for budgeting, timetabling, HR, and benchmarking. Bromcom's software is used by more than 5,000 schools and 390 multi-academy trusts (organizations that run multiple schools). Recent customer wins include Newport City Council, the Ministry of Defence, Warwickshire County Council, and the Northern Ireland Education Authority. ®

  •  
❌