China-state-aligned hackers used ARTEX, an AI-powered penetration-testing framework, to attempt access to more than 2,250 Microsoft 365 tenants following the ConnectWise Cloud Backup breach.

Microsoft attributed the attack to Storm-0940 and reported 2,900 sign-in attempts per minute, leaving security teams little time to investigate and block access.

The attackers abused stolen application credentials and permissions already approved by customers, rather than requiring users to enter passwords.

Earlier reporting on compromised ConnectWise backup credentials documented unauthorized sign-ins across 173 tenants.

That confirmed-access figure differs from Microsoft’s broader targeting count: not every attempted sign-in succeeded, and successful authentication alone does not prove data theft.

Researchers from Zscaler and Microsoft teams separately documented ARTEX abuse in reports published October 21. ARTEX is a security-testing framework, not a newly discovered malware family.

Microsoft attributed the ConnectWise attack to Storm-0940, while Zscaler examined a Chinese-speaking operator’s broader workflow without establishing that both investigations covered the same actor.

China-Linked Hackers Use ARTEX AI

According to Microsoft’s technical investigation report, Storm-0940 used ARTEX for scanning, password spraying, and OAuth application abuse.

Between October 10 and 14, its infrastructure targeted 327 accounts across eight organizations, generating more than 151,000 failed logons. Microsoft observed no successful authentication during that password-spray activity.

The group previously used stolen accounts for network access, as coverage of Storm-0940 password spray attacks explains. In the ConnectWise incident, however, stolen application credentials provided another route.

The attackers authenticated as trusted applications, using permissions already granted inside customer tenants without an interactive user sign-in.

After gaining control of multiple ConnectWise application identities, the attackers used Microsoft Graph to inspect environments and change application credentials.

Some activity involved identities, groups, and privileged roles. These changes could preserve access through other applications even after the original ConnectWise connection was disabled. Microsoft said several ARTEX-driven attacks reached privileged cloud access in under three hours.

Zscaler’s investigation showed how an operator combined ARTEX with Claude Code, Codex, and other AI workspaces. The framework divided goals into tasks, ran security tools, and retained findings.

Custom additions included nmap, sqlmap, nuclei, and Android analysis tools, extending its reach across websites, networks, and mobile applications.

The findings expand on earlier South Korean financial breaches involving ARTEX, with Zscaler finding targets across many countries and sectors.

Saved prompts requested personal records, phone numbers, payment credentials, and transaction data. Questions about selling stolen records suggested financial motives, but did not establish that any sale occurred.

Shared notes and synchronization scripts let separate AI sessions resume unfinished work. Prompts assigned DeepSeek initial research and GLM review duties, while other sessions used Grok configurations.

Zscaler cautioned that configured model names did not prove which underlying models answered requests. The operator also instructed agents to assume targets were authorized and reduced approval requirements.

What Defenders Should Check

Microsoft recommends keeping affected ConnectWise connections disabled until formal restoration guidance arrives.

Teams should preserve evidence before deleting applications and examine service-principal sign-ins, application credential additions, consent grants, and role changes.

Investigations should include previously authorized integrations, because removing the original connection may leave attacker-added credentials elsewhere.

Review should extend beyond published IP addresses to unusual Microsoft Graph activity, mailbox access, file downloads, forwarding rules, and unexpected owners. Microsoft said the activity did not stem from a vulnerability or compromise in its own systems, products, or services.

Indicators of compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post China-Linked Hackers Use ARTEX AI to Target 2,250 Microsoft 365 Tenants After ConnectWise Breach appeared first on Cyber Security News.

Railway has disclosed a security incident in which an unauthorized third party may have accessed customer environment variables, including some decrypted values. The cloud platform warned that the affected data could contain API keys, database passwords, and private registry credentials, and urged all customers to replace stored secrets.

The company published its security disclosure on October 21, 2026, after detecting unusual activity in systems that store these variables. Its initial findings suggest that only some users may be affected. However, Railway has not released an affected account count, identified the attacker, or explained how access was gained.

Railway Security Incident

Environment variables hold settings that applications need during builds and normal operation. Railway’s documentation explains that these values can include configuration details and secrets supplied to services. This makes the storage system a sensitive target because stolen credentials could give attackers access to connected services beyond Railway itself.

The key distinction is that Railway reported possible access to encrypted variables and, for some, decrypted contents. This does not establish that attackers broke the encryption. The notice does not explain how readable values may have been obtained, leaving that part of the investigation unresolved.

Railway believes the incident forms part of a recent series of attacks against platform companies aimed at compromising AI inference providers. These providers run AI models in response to user requests. Railway said it notified upstream providers and asked them to revoke keys proactively, but did not identify those providers.

The suspected focus on AI access reflects a wider credential theft risk. Cybersecurity News previously covered an LLMjacking attack involving a leaked AWS key, where stolen access was used to run paid AI models at the victim’s expense. Railway has not confirmed that similar misuse occurred in this incident.

Related reporting on AI agents exposing API keys and cloud secrets also shows why secret handling matters across modern development tools. That report describes exposure through configuration files, command output, and model context. It is background on credential risk, not evidence of how attackers entered Railway’s systems in this case.

Deployments Paused as Credential Resets Continue

Railway paused deployments during its investigation, preventing customers from releasing new application versions. Its incident status page confirmed that builds remained unavailable at 02:19 UTC on October 22. The restriction also affects recovery because some credential changes require services to be redeployed before applications can use the replacement values.

The company also began rotating all Railway storage bucket credentials as a precaution. Replacement credentials will appear automatically in customer dashboards. However, Railway said applications cannot be redeployed to pick up those credentials until builds return, creating an additional recovery hurdle for customers with services that depend on storage buckets.

Railway recommends immediately rotating all secrets stored as environment variables, including API keys and private registry credentials, and checking connected service logs for unusual activity. Customers should not wait for confirmation that their account was affected. The company has published guides covering database passwords, AI provider usage, cloud access, and GitHub activity.

Railway said it will email customers directly as affected accounts are confirmed. The investigation remains ongoing, with the full scope still unclear.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post Railway Security Incident: Hackers May Have Accessed Customer Environment Variables appeared first on Cyber Security News.

GitLab has released urgent security updates for a critical vulnerability that could let attackers run code on self-managed servers without logging in. Tracked as CVE-2026-110264, the flaw carries the maximum CVSS score of 10.0 and affects both GitLab Community Edition and Enterprise Edition. The company published the fixes on October 21, 2026.

The affected code reaches back to GitLab 7.0, released in 2014, giving the vulnerability a roughly 12-year history. That does not mean attackers have been using it for 12 years. GitLab’s advisory describes the risk but does not report confirmed attacks or provide a public exploit.

GitLab Remote Code Execution Flaw

According to GitLab’s official security advisory, the vulnerability involves an integer overflow when the server compiles a specially crafted regular expression. Regular expressions are patterns used to match text. Under certain conditions, processing an attacker-controlled pattern could allow arbitrary code to run on the server.

GitLab’s CVSS assessment describes a network-based attack with low complexity, no account privileges, and no required user interaction. It rates the possible impact on data privacy, data integrity, and service availability as high. However, the company has not disclosed the full conditions needed to reach the vulnerable code.

GitLab credited security researcher joaxcar with reporting the issue through its HackerOne bug bounty program. Its release notes also list Ruby regular-expression patches, providing further context about the affected software layer without revealing a complete attack path. Administrators should not assume the flaw requires access to a particular project or feature unless GitLab confirms that restriction.

Affected Versions and Available Fixes

The vulnerability affects GitLab CE and EE versions starting with 7.0. GitLab has fixed it in versions 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3, and 19.5.1. Earlier releases within those branches remain affected. The company extended the fix to four older branches beyond its standard patch releases.

Self-managed customers should upgrade immediately. GitLab.com already runs patched software. GitLab Dedicated tenants running 19.3.5-internal0, 19.4.2-internal0, or later already include the fixes and require no action, according to the notice. GitLab also says that when an advisory does not name a specific deployment type, all deployment types are affected.

This issue should not be confused with the earlier GitLab code execution vulnerability patched on October 12. That separate flaw, CVE-2026-97229, also involved regular-expression handling but affected a different version range. Installing that earlier update does not address this newly disclosed vulnerability.

GitLab has published two detection guides for self-managed environments, named “Onigmo native worker crash” and “Org mode render error burst.” These resources are intended to help security teams identify possible exploitation attempts. Their publication is not evidence that attacks have occurred, and the release notice does not establish either signal as proof of a successful compromise.

The patch release addresses 12 vulnerabilities overall. Another serious issue, CVE-2026-15723, carries a CVSS score of 8.2. When OmniAuth SAML and LDAP auto-linking are both enabled, an authenticated attacker could take over an existing LDAP-backed account without the victim’s involvement. CVE-2026-112212, rated 7.5, concerns poisoned OAuth and OpenID Connect discovery responses that could redirect certain flows to an attacker-controlled server.

These fixes follow other recent GitLab security updates, including a separate AI Gateway remote command execution vulnerability. Those reports concern different components and attack requirements, making accurate version checks more useful than assuming one GitLab update covers every related product.

Administrators should review GitLab’s upgrade instructions before deployment. The notice warns that database migrations can affect the process, with downtime for single-node installations and zero-downtime procedures available for suitable multi-node setups.

Versions 19.3.6 and 19.4.3 include regular migrations. GitLab normally makes detailed security issues public 90 days after patching, so teams should not delay updates while waiting for full technical details.

The GitLab fixes arrive alongside security updates for Node.js and PHP, adding to the patching workload for teams running web applications and development services.

Cyber Security News reports that Node.js released security updates addressing ten vulnerabilities across its 26.x, 24.x, and 22.x branches, with patched versions listed as 26.12.1, 24.22.1, and 22.23.4.

Meanwhile, PHP issued emergency patches for PHP2Shell, a pair of critical memory-handling flaws tracked as CVE-2026-109618 and CVE-2026-109619.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post 12-Year-Old GitLab Vulnerability Allows Remote Code Execution on Self-Managed Server appeared first on Cyber Security News.

GoDaddy launched a mass revocation of 404,607 SSL/TLS certificates after finding that issued certificates did not match its published certificate policies. The company missed its required revocation deadline, creating a second compliance issue. An updated customer notice says the incorrectly issued certificates were revoked on October 21, 2026.

The incident affects certificates issued under GoDaddy and Starfield certificate chains. Customers still using an affected certificate may face browser security warnings or website access problems until they install a replacement, according to GoDaddy’s customer guidance. Receiving a replacement alone does not confirm that the website is using it.

GoDaddy Revoking 404,607 TLS Certificates

According to the original incident report, a third party flagged differences between issued certificates and the profiles described in Starfield’s Certificate Policy and Certification Practice Statement, known as CP/CPS. These documents set out the rules the certificate authority follows when issuing certificates.

The differences involved certificate policy information, including policy object identifiers, or OIDs, and CPS URI policy qualifiers. These fields identify certificate policies and reference the authority’s published practices. The issued certificates did not match the documented profiles. The reports describe a compliance failure, not a confirmed theft of private keys.

GoDaddy stopped certificate issuance after confirming the report. Its investigation uncovered additional differences across affected profiles. The company corrected and published its documentation before resuming issuance. Further checks found similar problems in the older Starfield G2 chain, which was no longer actively issuing certificates.

Domain validated certificates made up most of the affected population. Starfield R1 DV accounted for 208,896 certificates, while Starfield G2 DV accounted for 187,159. Smaller numbers of organization validated and extended validation certificates were also affected across the GoDaddy and Starfield chains.

GoDaddy Missed the Revocation Deadline

The delayed revocation report cites Section 4.9.1.1 of the TLS Baseline Requirements. For the stated policy violation, affected certificates should be revoked within 24 hours and must be revoked within five days, except for short-lived subscriber certificates. The specified revocation reason is “superseded.”

GoDaddy began contacting subscribers on October 14. Its outreach included customers holding large certificate inventories and organizations providing government, financial, and health services. However, only 170,566 certificates had been revoked when the October 18 deadline passed at 23:45 UTC.

By 05:29 UTC on October 19, the revoked total had reached 227,422. GoDaddy said dedicated teams were handling customer contact, replacement, revocation, and progress tracking through email, SMS, and phone calls. Its later customer notice states that the incorrectly issued certificates were revoked on October 21.

Affected administrators should review the SSL certificate section of their GoDaddy account and follow any replacement notice. GoDaddy warns that an updated certificate can exist in the account while the domain continues serving the old certificate. Customers receiving an installation alert should download and install the replacement immediately.

The case echoes earlier DigiCert certificate revocations following a DNS validation error, although the underlying failures differ. It also highlights the operational concerns covered in Cybersecurity News’ report on certificate mismanagement.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post GoDaddy Revoking 404,607 TLS Certificates Following Compliance Failures appeared first on Cyber Security News.