Investigation ongoing. All times below are UTC.
On 22 October 2026, Avalonia came under a sustained, unauthorised attack targeting several of our services. Our investigation has confirmed that the attacker gained access to the content management system (CMS) used by our marketing website.
The attacker obtained access through a CMS administrator credential that we mistakenly exposed in JavaScript delivered to website visitors. We have revoked that credential, removed it from the website and restricted CMS permissions.
While the attacker targeted a wide range of our infrastructure, our investigation has identified unauthorised access only to the website CMS.
Our findings so far confirm:
- No evidence of customer data exposure. We have found no unauthorised access to customer portal records, payment information or licence keys.
- No identified compromise of core systems. Attempts to access other customers' accounts, our licensing systems and restricted product source code were unsuccessful.
- No identified supply chain impact. All 39 observed attempts to publish packages to our NuGet feeds were rejected. We have found no evidence of package tampering or restricted product source code being leaked.
- No customer action is required based on our current findings. Customers DO NOT need to reset portal passwords, replace licence keys or reinstall packages.
We take this incident seriously. The CMS compromise resulted from a security mistake on our part, and we have taken steps to address it. Our investigation remains ongoing, and we will update this post if our assessment changes.
Below, we explain what happened, what the evidence shows and the actions we have taken.
What happened
The first identified requests arrived at 06:06 on 22 October. Over the following day, the attacker used automated tooling, Tor, other network addresses and disposable email accounts to target multiple Avalonia services.
Customer portal and licensing
The attacker created accounts on our customer portal and attempted to access other customers' subscriptions, impersonate users, elevate account permissions and upload an HTML file through our support system.
The observed attempts to access other customers' data or restricted resources were rejected. Tens of thousands of requests targeting our core systems did not result in unauthorised access.
In a later session, between 21:36 and 23:16 on 22 October, the attacker used three additional accounts and five user profiles to test access to other accounts' users, licences, subscriptions and support tickets, as well as Enterprise source-code downloads. These attempts were also rejected.
The attacker obtained two trial subscriptions through the normal self-service signup process, using accounts they had previously created. Those trials did not provide access to other customers' records or Enterprise source code, and we have since cancelled these trial subscriptions.
Our investigation has found no evidence of customer account takeover, access to another customer's records or compromise of our licensing systems.
Package feeds
The attacker made 39 attempts to publish packages to our NuGet feeds. All 39 were rejected.
Our subsequent review found no packages published by the attacker and no evidence of package tampering. Downloads from feeds intentionally available to the public did not provide publishing permissions or access to restricted product source code.
For a software supplier, attempts to compromise package publishing are particularly important. A successful attack against a package feed could introduce malicious code into downstream developer environments, builds and applications.
That is why we have treated these attempts as a priority in our investigation, even though none of the observed publishing attempts succeeded.
Internal tools
The attacker also targeted our test management service.
Sign-in attempts failed. Although the attacker was able to create an account, they could not activate it or gain access to the service. This is an internal tool used to test Avalonia and does not store customer or private information. We subsequently took it offline as a precaution.
Website CMS
The CMS manages content intended for public consumption, including website pages, blog posts, careers information, customer success stories and release notes. It also hosts licence agreement text used by our customer portal. It runs on isolated infrastructure, separate from our other services, and contains no sensitive information.
It does not store customer account records, payment information, licence keys or restricted product source code. However, it does hold staff CMS accounts, including names, work emails, and hashed passwords, as well as unpublished draft content. Because it controls public-facing content and houses staff CMS credentials, unauthorised administrator access remains a serious security incident.
We identified two weaknesses affecting the CMS.
Public submission permissions
Earlier on 22 October, an overly permissive public submission endpoint allowed three showcase records to be created. We removed those records that morning and subsequently removed the anonymous write permission.
Exposed administrator credential
Later, the attacker used an exposed administrator token to gain access to the CMS. Recorded administrator activity ran from 22:37 on 22 October until 01:22 on 23 October. We detected the unauthorised activity at 04:37 on 23 October and revoked the token at 05:13.
Within the CMS, the attacker:
- Created automation scripts.
- Uploaded three small test files.
- Created a draft blog post that was never published.
- Added another CMS account.
We have removed the draft post and remaining uploaded files. The attacker-created account has been suspended and its token cleared. We also preserved CMS activity records, revision history, database backups and uploaded files to support the ongoing investigation.
How the CMS was compromised
The CMS compromise resulted from a mistake in how we built the marketing website.
A CMS administrator token was stored in an environment variable. An unexpected configuration led to the environment variable being embedded directly into the JavaScript delivered to browsers. As a result, the administrator token became publicly accessible.
This credential should never have been included in client-side code. It should have remained on the server, with permissions limited to those required by the website. This was our mistake, and we have corrected it.
We revoked the exposed token, rebuilt and deployed the website with CMS credentials removed from browser-delivered code, purged the old JavaScript from our cache and tightened CMS permissions.
Our review found that the exposed token had been present since at least April 2026. We have found no signs of earlier malicious activity or exploitation associated with this credential before the current incident.
Attempts to move beyond the CMS
After gaining administrator access on our CMS, the attacker attempted to use CMS automation functionality to reach the underlying server and other systems. The recorded scripts executed within the CMS sandbox. Attempts to read the host environment or connect to internal services failed.
The attacker also configured requests to external collection endpoints. The retained automation records show that these requests contained test text and sandbox diagnostic results. They did not contain CMS content, credentials or personal or sensitive data.
Our investigation has found no evidence that the attacker moved beyond the CMS into the underlying host, our internal network or systems that manage and store customer data.
What we have done
Our response has focused on containing the compromise, preserving evidence, reviewing the attacker's activity and reducing the possibility of similar attacks succeeding.
We have:
- Revoked compromised credentials. We revoked the exposed CMS administrator token, suspended the associated account and the attacker-created account, and cleared its token.
- Secured the website. We rebuilt and redeployed the website without CMS credentials in client-side JavaScript and purged cached copies of the affected files.
- Restricted CMS access. We removed anonymous write permissions, disabled public registration and reduced staff administrator access in favour of roles with only the permissions required.
- Strengthened portal authentication. We corrected the portal's sign-in code attempt limit and introduced additional rate limiting on authentication endpoints.
- Reduced infrastructure exposure. We removed obsolete public portal hostnames, expanded malicious-traffic blocking, including blocking Tor traffic, and removed public access to several internal services.
- Reviewed infrastructure credentials. We identified and proactively revoked an overprivileged infrastructure key. Our investigation found no evidence it was misused.
- Preserved investigation evidence. We retained relevant CMS activity records, revision history, database backups and uploaded files.
The public showcase submission form remains temporarily paused. Further improvements to infrastructure access, credential management, monitoring and administrative protections are underway alongside the ongoing incident response.
Reporting the incident
We submitted an initial early-warning notification through the European Union's Cyber Resilience Act (CRA) reporting process within 24 hours of first awareness. Although the confirmed compromise was limited to our website CMS, that system also supplies content to the customer portal, including product licence agreement text.
Given this dependency, we have taken a precautionary approach to reporting while continuing to assess the incident's precise regulatory scope. We believe prompt reporting and transparent communication are important parts of our responsibility to customers and the wider software ecosystem.
We will supplement our notification as the investigation progresses.
A persistent and adaptive attack
This was not a single attempt against one endpoint. The attacker systematically tested multiple services, repeatedly attempting to cross security boundaries and obtain higher levels of access.
They used Tor, rented cloud servers, and disposable email accounts, changing network addresses and identities as earlier routes were blocked. Even after we blocked known addresses and attack routes, attempts continued using new infrastructure.
Our response has therefore focused not just on individual IP addresses, but also on identifying suspicious request patterns, account behaviour and attempts to access restricted resources.
The request signatures and execution patterns observed during the attack against Avalonia point to ARTEX, an open-source, AI-assisted penetration-testing framework, or a derivative of it.
While recent industry reports have noted the use of ARTEX by state-aligned threat actors in other campaigns, ARTEX is a publicly available tool. Its use alone does not identify the operator, and we have not attributed the attack against Avalonia to any specific group or organisation.
The incident demonstrates how attackers can use automation to test numerous services, credentials and access controls in a short period of time.
In our case, the access controls protecting customer accounts, restricted product source code and package publishing rejected the observed attempts. However, a separate mistake in how we handled a CMS administrator credential gave the attacker access to our website content management system.
What this means for customers
Our investigation remains ongoing. Based on the evidence reviewed so far, we have identified one compromised application: the website CMS.
We have found no evidence of unauthorised access to customer portal data, a leak of restricted product source code or tampering with published packages.
The CMS credential exposure and overly permissive submission endpoint were security mistakes we were responsible for correcting. We have addressed both and are continuing to strengthen the protections around our infrastructure. No customer action is required based on our current findings.
Customers do not need to reset their portal passwords, replace licence keys or reinstall Avalonia packages as a result of this incident.
We will update this post if our assessment changes and contact affected people directly if we identify a need for individual notification or action.
Protecting our customers, developers and the software supply chain remains a priority. We will continue to investigate this incident, improve our defences and share material findings as they become available.