7 verified findings from 1 run · 1 update to prior coverage · the settled record for this UTC day, in the classic brief order.
Criticality
Kind
Topic
Region
TL;DR · the day in one read
01An attacker defeated Switzerland's cantonal vehicle-registry rate limits at scale, and two operators were then extorted. Five Swiss cantons (Vaud, Aargau, Lucerne, Schaffhausen, Zug) and canton Valais separately disclosed on 2026-08-28 that an unknown party bypassed the built-in per-person daily query limit on their public vehicle-owner lookup portals to harvest plate/name/address data at scale in mid-August; Valais's separate "ecari" platform also leaked approximate owner birthdates through additional, non-standard extractions. Both the eAutoIndex operator (Viacar AG) and canton Vaud report subsequent extortion attempts, which they did not act on. No core government IT system was compromised; only the public-facing lookup interfaces were abused. →
02ServiceNow patches four unauthenticated flaws in its AI Platform and Now Platform, three of them maximum severity. ServiceNow's 27 August 2026 advisory (KB3152242) fixes four flaws: three unauthenticated, CVSS4.0 10.0 issues in the AI Platform (two code-injection flaws and one SQL injection, per ServiceNow's own classification) plus a related CVSS 8.7 sandbox escape in the Now Platform. Hosted instances are already patched; self-hosted and partner-hosted customers must apply the fix themselves. No exploitation is reported for any of the four, and no public proof-of-concept is reported for the three maximum-severity flaws. →
03A pre-auth RCE chain in PaperCut NG/MF was exploited before any patch existed; tested maintenance releases now replace three emergency patches. PaperCut NG and PaperCut MF (all versions) carry an unauthenticated remote-code-execution chain, CVE-2026-81578 (auth bypass, CVSS4.0 8.8) and CVE-2026-82078 (unsafe dynamic class loading, CVSS4.0 9.4), that PaperCut confirmed under active exploitation on 2026-08-27, before any CVE or patch existed. Fully tested maintenance releases 26.0.5, 25.0.13 and 24.1.10 (10 September 2026) replace the emergency patches and are the vendor's recommended build (the September bulletin, revised 2026-10-13, now names 24.1.11 for v24); servers still on Emergency Patch Release 1 or 2 need to upgrade now. There is no fix for v23 and earlier, and Huntress estimated on 28 August that 47% of the PaperCut installs it tracks ran v23 or older. GreyNoise now documents an AI-agent-orchestrated mass-exploitation campaign against this same chain, compromising at least 440 instances across 395 identified organizations since 31 August 2026, reaching full domain admin in as little as five minutes via legacy Active Directory escalation paths. watchTowr's write-up of 2026-10-09 shows the 28 August emergency build could still be taken without authentication through the Setup Wizard forms, and names CVE-2026-82077, an administrator-only Scan-to-Fax code-execution flaw that the vendor lists as fixed in 26.0.5, 25.0.13 and 24.1.10. Hunt.io's recovery of the attacker's open directories (2026-10-15) adds a second route to code execution through PaperCut's XML-RPC API, usable when its address allowlist is too permissive or no explicit token is set, a cron-kept reverse SOCKS tunnel, and live pivots into 45 victims, with Switzerland among the countries listed. →
04A phone call alone could fingerprint the callee's device and patch level, and GSMA's warning suggests the gap is not Germany-specific. An investigation by Bayerischer Rundfunk (BR), corroborated by heise, found that Germany's three mobile network operators (Deutsche Telekom, Vodafone, Telefónica/O2) forwarded device-identifying data (a callee's full IMEI, or smartphone model and OS version) to the calling party during call setup, in certain unspecified network/device constellations. The GSMA confirmed the flaw on inquiry and warned its 1,000+ member operators worldwide to review their networks; Germany's BfV assessed it as security-relevant, citing near-certain exploitation by foreign intelligence services. A parallel April-2026 finding in Norwegian networks suggests the underlying gap is not carrier-specific. →
05A working public exploit for an Exchange mailbox-move endpoint lands sixteen days after Patch Tuesday, and MSRC's exploitability rating has not moved. CVE-2026-62911 (CVSS3.1 8.0), patched in Microsoft's 11 August 2026 Exchange Server security release and originally rated "Exploitation Less Likely," now has working exploit code published on GitHub (around 27 August 2026). The flaw is a missing channel-binding check on the MRSProxy mailbox-move endpoint that lets a relayed Negotiate authentication exchange be treated as the relayed account, giving an attacker who can relay that exchange full mailbox access across the organization. No in-the-wild exploitation is reported. →
On 2026-08-28, five Swiss cantons (Vaud, Aargau, Lucerne, Schaffhausen and Zug) issued a joint statement, and
canton Valais a separate one, disclosing that an unknown party had automatically harvested vehicle-owner data at
scale from their public online lookup services in mid-August (cash.ch, 2026-08-28).
For the five-canton group the vector was eAutoIndex, a shared lookup platform operated by Viacar AG (Aarau) for
multiple cantonal road-traffic offices; the platform normally
receives more than 10,000 legitimate owner queries a day across the five cantons
(cash.ch, 2026-08-28).
The joint statement records that the actor circumvented eAutoIndex's own anti-abuse control, ordinarily capped at
five queries per person per day, to compile registration-plate numbers together with the associated owner's name
and address at volume (cash.ch, 2026-08-28).
Cantonal officials characterise this as abuse of a legitimate public-disclosure mechanism rather than a conventional
data breach: no authentication was bypassed, the retrieval interface exposed only data already publicly disclosable
under Swiss federal road-traffic law, and no data that owners had opted to block from public disclosure was exposed
(cash.ch, 2026-08-28).
Canton Valais reported a separate incident the same day affecting "ecari", a different vehicle-lookup module
supplied by an external partner to its own cantonal road-traffic and navigation service. There, the actor went
beyond the intended query logic of the lookup interface through additional extractions to also obtain approximate
owner birthdates, a materially more sensitive field than the plate/name/address set exposed via eAutoIndex, and one
not normally reachable through an ordinary query
(Blick, 2026-08-28).
Both the eAutoIndex operator (Viacar AG) and the canton of Vaud state they were subject to extortion attempts
following the harvesting, which they did not act on
(Blick, 2026-08-28).
The five eAutoIndex cantons have filed or plan to file criminal complaints, and Viacar AG has introduced additional
technical access restrictions on eAutoIndex and is evaluating further controls
(cash.ch, 2026-08-28).
Valais separately states it has filed its own criminal complaint and has hardened access security on the affected
"ecari" system
(Blick, 2026-08-28).
Neither the identity nor the number of actors involved is known, and no exploitation of the underlying road-traffic
office IT systems (as opposed to the public lookup interfaces) is reported by any cantonal authority
(cash.ch, 2026-08-28;
Blick, 2026-08-28).
No source names the specific bypass technique (IP rotation, missing server-side session or device fingerprinting,
distributed request sourcing, or another anti-abuse gap), an open question worth flagging for any defender who
operates a similar public per-identity rate-limited lookup service. Cantonal officials warn of a plausible follow-on
fraud vector: attackers or downstream buyers of the harvested plate/name/address/approximate-birthdate combination
could send deceptively authentic-looking demands for fake fines, vehicle-inspection fees, or foreign toll charges
(cash.ch, 2026-08-28).
Ordinarily, the number of queries on 'eAutoIndex' per person and per day is limited to five.
According to current findings, the retrieval of the data occurred via a technical interface that exclusively permitted access to publicly viewable data. It can be ruled out that blocked data was exposed, according to Probst. It is not an actual data leak but rather the abusive use of a public information-lookup facility.
The public-data leak also affected Valais: the 'ecari' search module, supplied by a partner external to the road-traffic and navigation service, was likewise targeted. Through additional extractions, the hacker was also able to access approximate date-of-birth data that is not normally accessible via an ordinary query.
TrendAI (Trend Micro) Research published a technical analysis, dated 2026-08-20, of a cluster of fourteen trojanized
npm packages, small, functional calendar/streak date-math utilities such as streak-metrics-math, kit-map-vim
and streak-map-cache, that each bundle a Linux ELF binary alongside genuine, working date-helper code
(TrendAI Research, 2026-08-20).
The package's loader re-exports the genuine helpers so the package works as advertised, then runs an async IIFE
(immediately invoked function expression) evaluated at module load: it marks the bundled binary executable, verifies
its hash against a hardcoded constant, and spawns it detached so it outlives the importing Node process
(TrendAI Research, 2026-08-20).
No install hook or exported function call is involved, so --ignore-scripts provides no coverage, and a single
transitive import anywhere in a dependency graph (even one the developer never directly selected) is sufficient to
trigger execution (TrendAI Research, 2026-08-20).
The dropped binary is RedShell, the native Linux implant for RedC2 4.0, a modular, actively-developed cross-platform
(Windows/macOS/Linux) command-and-control framework marketed on Hack Forums. On execution, RedShell ignores SIGPIPE,
double-forks to daemonize, and connects to a hardcoded primary C2 host over TCP with aggressive keepalive tuning,
wrapping the session in TLS with certificate verification explicitly disabled, accepting any server certificate,
self-signed or otherwise, without validation, and TLS 1.2 enforced as the minimum version
(TrendAI Research, 2026-08-20).
A persistent per-host installation ID is cached in a dotfile under $HOME so re-infection state survives restarts.
RedShell exposes a broad Linux-native command set to the operator: interactive shell execution, SSH-key and
browser-credential harvesting, database discovery, bulk exfiltration over HTTP or to third-party file-sharing
services, fileless ELF execution via memfd_create, arbitrary shellcode execution via mmap, dlopen-based
shared-library loading, SOCKS5 proxying and TCP port forwarding, and cross-network reverse-shell tunnelling brokered
through the C2 server; persistence is established through cron, .bashrc, a user-level systemd service, or an XDG
autostart entry (TrendAI Research, 2026-08-20).
The framework additionally ships an LLM-backed component RedC2's own documentation calls Red Agent, a different
tool from Wiz's own similarly-named "Red Agent" autonomous red-teaming tool, an unrelated defensive research
product, exposed via a /ra command in the beacon terminal, described as trained on the framework's command set
to break a single natural-language operator prompt into an ordered chain of beacon commands
(TrendAI Research, 2026-08-20).
Detection concept: process-creation telemetry showing a Node.js/npm-installed package's module import immediately
spawning a detached, double-forking child process that opens an outbound TLS session accepting an invalid or
self-signed certificate without validation, legitimate npm packages that bundle native binaries (for example via
prebuilt node-gyp addons) do so at install time through a documented hook, not as a side effect of a plain import
with no exported function called. Triage: a package with a bundled native binary that is invoked only from
install-time hooks is routine; one invoked from a plain module-load side effect, with no install hook present at
all, is the discriminator.
One import anywhere in the dependency graph is sufficient, including from a transitive dependency the developer never selected.
Certificate verification is explicitly disabled via SSL_VERIFY_NONE, meaning the malware will accept any server certificate without validation, allowing the C&C operator to use self-signed or otherwise invalid certificates freely.
RedC2 ships with an AI assistant called Red Agent, an LLM-backed command execution layer that turns natural-language intent into framework beacon commands. It is exposed through /ra in any beacon terminal, in both the web UI and the EXT client.
CVE-2026-62911 (CWE-294, Authentication Bypass by Capture-Replay) was patched in Microsoft's 11 August 2026 Exchange
Server security release, at the time rated "Exploitation Less Likely"
(Microsoft Security Response Center, 2026-08-11).
NCSC-NL revised its own advisory (NCSC-2026-0289) on 2026-08-28 specifically to record the public proof-of-concept
and raised its likelihood/damage assessment from medium/high to high/high as a result
(NCSC-NL, 2026-08-28).
The flaw sits in the MRSProxy endpoint Exchange exposes for cross-server mailbox moves: MRSProxy accepts Negotiate
authentication but never validates channel bindings, the check Extended Protection for Authentication depends on
(Franky's Web, 2026-08-27).
Without that check, an attacker can relay the authentication of the server account to
MRSProxy and be treated as that account
(Franky's Web, 2026-08-27);
Microsoft's own FAQ confirms the resulting
access lets an attacker "take over the mailboxes of all Exchange users... send emails, read emails, download
attachments"
(Microsoft Security Response Center, 2026-08-11).
The flaw was discovered by Orange Tsai of DEVCORE Research Team and demonstrated at Pwn2Own Berlin 2026 as one link
in a three-vulnerability chain that together achieved SYSTEM-level remote code execution on Exchange, reported to
Microsoft through the Zero Day Initiative
(Franky's Web, 2026-08-27).
Working exploit code was published on GitHub around 27 August 2026 (sixteen days after the patch) and MSRC's
exploitability rating has not been revised since its 11 August publication despite the public proof-of-concept
(Franky's Web, 2026-08-27).
Affected are all Exchange Server builds below the August 2026 cumulative/security update across Exchange Server SE,
2019 (CU14 and CU15) and 2016 (CU23); there is no workaround via Exchange Emergency Mitigation, so the update must be
installed directly, and updates for Exchange 2016 and 2019 are available only through Microsoft's paid Extended
Security Updates (ESU) program; organizations without a current ESU license will not receive the patch
(Franky's Web, 2026-08-27).
No in-the-wild exploitation has been reported as of this writing.
MSRC's own CVSS vector scores the precondition as PR:L/UI:R, an "authorized attacker" with some user
interaction (Microsoft Security Response Center, 2026-08-11), but Franky's Web's technical description, Germany's CERT-Bund and the
Dutch NCSC-NL all independently characterise the flaw as exploitable by an attacker with no authentication at all.
CERT-Bund states the public exploit "enabl[es] the complete remote takeover of systems without authentication" (translated from German)
(CERT-Bund, 2026-08-28), and NCSC-NL's own advisory states
plainly that the flaw "allows an unauthenticated attacker to execute arbitrary code" (translated from Dutch)
(NCSC-NL, 2026-08-28). A third-party technical
reconstruction of the exploit chain narrows what "coerce or capture" requires in practice: MB VRED's own most
plausible hypothesis (not a confirmed finding) is that the attacker needs an existing foothold on the
internal, domain-joined network to issue an MS-EFSR (PetitPotam-style) coercion call against one Exchange
server, capturing its machine-account authentication and relaying it to the MRSProxy endpoint on a different
Exchange server ("The attacker sits inside the network, especially inside a domain-joined PC!") and the
technique needs at least two Exchange servers in the environment, since "the captured hash cannot be relayed to
itself." MB VRED frames this as requiring "lot of non-realistic conditions to be exploited in the real world",
specifically, outbound connectivity from an Exchange server and inbound access on ports domain users do not
normally reach it on, closing with "So, for the defensive guys, don’t be panic!"
(MB VRED, 2026-08-13). Weighing two
independent national CERTs' plain "unauthenticated" characterization against both the vendor's own CVSS
labelling and this single, uncorroborated hypothesis about the network position it may actually require, any
Exchange server below the August 2026 build should still be patched on the CERTs' own stated urgency, but MB
VRED's own caveats are a reason for caution before assuming this is exploitable from the open internet without
any existing foothold on the target's network. Detection concept, in analyst judgement: authentication and session telemetry for MRSProxy/EWS access
running under the Exchange server's own machine-account context but originating from unexpected source hosts, a
legitimate mailbox move originates internally, not via relayed external traffic, with Windows Security Event 4624
Logon Type 3 network logons in that account context as the platform-specific anchor.
Working exploit code has surfaced for the critical Exchange vulnerability CVE-2026-62911 from the August update.
This endpoint accepts Negotiate authentication but does not check the so-called channel bindings. It is precisely this check that enforces Extended Protection.
Authentication bypass by capture-replay in Microsoft Exchange Server allows an authorized attacker to elevate privileges over a network.
What privileges could be gained by an attacker who successfully exploited the vulnerability? The attacker would be able to take over the mailboxes of all Exchange users, attackers can send emails, read emails, download attachments.
A PoC exploit has been published for the critical vulnerability CVE-2026-62911 in Microsoft Exchange, enabling the complete remote takeover of systems without authentication. (translated from German)
Currently, however, we are only aware of 9 Exchange servers 2016/2019 in Germany on which patches issued under ESU are installed. (translated from German)
BSI, via heise Security
The attacker sits inside the network, especially inside a domain-joined PC!
This one works only for multiple Exchange servers setup because the captured hash cannot be relayed to itself!
It requires lot of non-realistic conditions to be exploited in the real world:
Following a press inquiry, Germany's CERT-Bund (part of the BSI) disclosed on 2026-08-28 that most of the country's on-premises Exchange population had still not applied the August patch: "Currently, however, around 85% of on-premises Exchange servers in Germany are still vulnerable to this vulnerability" (translated from German) (CERT-Bund, 2026-08-28). BSI states it has been proactively notifying German network operators about still-vulnerable systems in their networks since 2026-08-14 (heise Security, 2026-08-31). For the small population of Exchange 2016/2019 installs still supported only through the paid Extended Security Updates program, BSI says it is aware of only nine servers in Germany with the ESU patch installed (BSI, via heise Security, 2026-08-31). BSI's standing advice is unchanged: restrict internet-facing access to an Exchange server's web-based services to trusted source IP ranges, or place it behind a VPN (BSI, via heise Security, 2026-08-31).
This is the operationally important delta for any DACH-region on-prem Exchange operator, including Swiss cantonal and communal administrations running Exchange on-premises: German telemetry indicates that most operators in a comparable environment have not applied a two-week-old patch against a pre-auth, mailbox-wide takeover chain with public exploit code. "We applied the August patch" should be verified against the actual installed build number, not assumed from a routine patch-cycle checklist.
No Exchange Emergency Mitigation workaround exists (Franky's Web, 2026-08-27), but BSI's standing advice is to restrict internet access to an Exchange server's web-based services to trusted source addresses or place them behind a VPN (BSI, via heise Security, 2026-08-31), which reduces exposure until the August update is installed. The takeaway had said there was no interim mitigation at all.
ServiceNow's 27 August 2026 advisory (KB3152242) discloses four flaws, found through the vendor's own security
research and responsible-disclosure program rather than external report
(ServiceNow, 2026-08-27). Three,
CVE-2026-18885, CVE-2026-18886 and CVE-2026-74820, are unauthenticated flaws in the ServiceNow AI Platform that
ServiceNow's own text classifies as critical: CVE-2026-18885 as code injection letting an unauthenticated user
execute arbitrary code and gain access to, or modify, instance data; CVE-2026-74820 as SQL injection letting an
unauthenticated user execute arbitrary SQL against the instance's own database; CVE-2026-18886 also as code
injection, but described as letting an unauthenticated user create or modify instance data, resulting in privilege
escalation
(ServiceNow, 2026-08-27). The
Hacker News reports the same three at a numeric CVSS4.0 score of 10.0; ServiceNow's own advisory gives only the
qualitative "critical" label, never a numeric score
(The Hacker News, 2026-08-28). The
Hacker News, reporting on the same advisory, assigns each a more specific mechanism: CVE-2026-18885 as a code
injection in the GraphQL Composite Data API, CVE-2026-74820 as a SQL injection reached through a dynamic-schema
ORDER BY clause, and CVE-2026-18886 as an improper-access-control flaw in the system-configuration image-upload
processor enabling privilege escalation, a classification that differs from ServiceNow's own "code injection"
description of the same id
(The Hacker News, 2026-08-28). All
three share the identical CVSS4.0 vector AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H per The Hacker
News's reporting, network-reachable, low attack complexity, no privileges, no user interaction, high impact to the
vulnerable component and connected systems
(The Hacker News, 2026-08-28). A
fourth, related flaw, CVE-2026-6876, is a sandbox escape ServiceNow's own text describes as letting an
unauthenticated user execute arbitrary code within the Now Platform
(ServiceNow, 2026-08-27). The
Hacker News reports the CVSS4.0 vector ServiceNow assigned to it in fact specifies PR:L (low privileges required)
rather than none (an inconsistency with ServiceNow's own "unauthenticated user" prose) scores it 8.7, and connects
it to CVE-2026-6875, a pre-auth ServiceNow sandbox escape Searchlight Cyber reported to ServiceNow on 1 April 2026,
with the vendor's own advisory for it published on 13 July 2026
(The Hacker News, 2026-08-28).
ServiceNow deployed the update to hosted instances directly and provided it to partner and self-hosted customers,
who must apply it themselves; those customers should verify their instance version against the vendor's fixed-build
table, spanning the Xanadu, Yokohama, Zurich and Australia release lines, each with its own minimum hotfix
(The Hacker News, 2026-08-28). ServiceNow
reports no awareness of exploitation for any of the four flaws, and The Hacker News found no public proof-of-concept
for the three maximum-severity flaws as of 28 August 2026
(The Hacker News, 2026-08-28).
Because ServiceNow is its own CVE Numbering Authority and none of the four flaws meet NIST's current
post-April-2026 enrichment criteria (CISA KEV listing, federal-software impact, or an Executive Order 14028 critical
designation), ServiceNow's own severity ratings are the only assessment on record for any of them
(The Hacker News, 2026-08-28), a
vulnerability-management process that ranks purely on NVD-enriched severity will not see the urgency here.
Detection concept: ServiceNow instance and application audit logs, and GraphQL API access logs, for anomalous or
malformed API mutations originating from unauthenticated sessions; database-audit telemetry for dynamic-schema
queries carrying non-schema tokens; system-configuration change-audit records for writes not tied to an
authenticated administrative session. No public exploit code exists yet, so this is patch-priority guidance rather
than an active-exploitation hunt.
ServiceNow has remediated a code injection vulnerability that was identified in the ServiceNow AI platform. This vulnerability could enable an unauthenticated user, in certain circumstances, to execute arbitrary code in the ServiceNow platform and gain access to, or modify, instance data beyond what was intended.
ServiceNow has remediated a SQL injection vulnerability that was identified in the ServiceNow AI platform. This vulnerability could enable an unauthenticated user, in certain circumstances, to execute arbitrary SQL statements against the instance's underlying database
ServiceNow
A code injection vulnerability in the GraphQL Composite Data API that could enable an unauthenticated user to execute arbitrary code and gain access to, or modify, instance data
An improper access control vulnerability in the system configuration image upload processor that could enable an unauthenticated user to create or modify instance data, resulting in privilege escalation
None of the four flaws appeared in the catalog as of August 28, 2026, leaving ServiceNow's ratings as the only severity assessment on record.
The company said it deployed a security update to hosted instances and provided the update to its partners and self-hosted customers, which leaves organizations that run their own instances to apply the fixes themselves.
Bayerischer Rundfunk (BR) published an investigation, corroborated the same window by heise, that found Germany's
three mobile network operators (Deutsche Telekom, Vodafone and Telefónica/O2) forwarded device-identifying data to
the calling party during call setup, before the callee ever answered
(BR24, 2026-08-27).
Across more than 70 test calls, Telekom's and O2's networks in several cases forwarded the callee's full 15-digit
IMEI (confirmed by Wireshark packet captures of the call-setup traffic) and Telekom's and Vodafone's networks
separately exposed the callee's smartphone model and operating-system version, specific enough to reveal whether a
target device was missing a given security update
(BR24, 2026-08-27;
heise Security, 2026-08-27).
The leak occurred only in certain unspecified network/device constellations rather than on every call, and BR could
not establish since when the gap existed; BR notified the three operators in late June 2026, after which Vodafone
said it had "further narrowed" transmitted call data, Telekom said in mid-August it would adjust its network, and
Telefónica said it had implemented technical measures; all three state they otherwise meet international industry
standards (BR24, 2026-08-27).
The GSMA confirmed the flaw on inquiry and, per a nine-page briefing BR obtained, warned its 1,000+ member operators
worldwide to review their networks and filter unnecessarily transmitted call-setup information, an implicit
acknowledgment that the same signaling gap plausibly extends beyond Germany's three carriers to any GSMA member
network (BR24, 2026-08-27).
Germany's domestic security service (BfV) assessed the flaw as security-relevant, stating that given cyberattacks
against mobile devices by state-affiliated actors already on record, it is "near-certain" that foreign intelligence
services use such information for their own purposes
(BR24, 2026-08-27).
A scenario in the Bundeswehr's own magazine "Y" illustrates the mechanism: correlating a soldier's IMEI between a
domestic posting and a later deployment abroad (its example is a training ground in Lithuania) could put that
individual "in a spy's focus"; the Federal Ministry of Defense separately told BR that intelligence services can use
such device identifiers to build movement profiles and identify individuals
(BR24, 2026-08-27).
HPI mobile-security researcher Jiska Classen called it a serious flaw enabling mass profile-building and said it
shows how poorly such carrier systems are tested
(BR24, 2026-08-27).
SRLabs founder Karsten Nohl, asked by heise to elaborate, added that device-model exposure also enables more
targeted attacks and IMEI cloning, while stating he sees no dramatic security impact in the finding on its own
(heise Security, 2026-08-27).
BR notes the finding parallels an April-2026 discovery of a similar flaw in Norwegian networks by Mnemonic researcher
Harrison Sand, who shared his methodology with BR, suggesting the underlying signaling gap is not specific to any
one carrier or country
(BR24, 2026-08-27).
Neither BR nor heise names the precise signaling layer, an SS7 interconnect field, a Diameter/IMS parameter, or a
VoLTE SIP header, carrying the leaked data; this is recorded as an unresolved open question, not an invented
mechanism. Detection concept for a telco SOC or network-security team: audit outbound call-setup signaling at the
interconnect boundary for device-identifying parameters (IMEI, UE capability/OS-version fields) reaching the
calling party or a foreign network, consistent with GSMA and IETF guidance (RFC 7254, RFC 7255) that such fields be
anonymized or stripped before leaving the home network
(heise Security, 2026-08-27).
Hardening lever: filter or strip unnecessary device-identifying call-setup parameters at the network edge, per the
GSMA's own briefing recommendation.
In the networks of Telekom and Telefónica (O2), IMEI numbers reached the caller in several cases.
The Federal Office for the Protection of the Constitution (BfV) assesses the security vulnerability discovered by BR research, on inquiry, as "security-relevant".
After BR approached the association with questions, it warned its more than 1,000 member companies, which also include the German network operators.
The EU Cyber Resilience Act's reporting obligations bind from 11 September 2026, requiring manufacturers of
"products with digital elements" placed on the EU market to report actively exploited vulnerabilities and severe
incidents through ENISA's centralised Single Reporting Platform (SRP)
(NCSC-FI / Traficom, 2026-08-28).
On 2026-08-28, with two weeks left before the obligation binds, NCSC-FI published a manufacturer checklist
supplying the concrete notification clock: an early warning within 24 hours of the manufacturer becoming aware of an
actively exploited vulnerability or severe incident, supplemented within 72 hours; for a vulnerability, a final
report within 14 days after a corrective or mitigating measure becomes available; for a severe incident, a final
report within one month of the incident notification
(NCSC-FI / Traficom, 2026-08-28).
ENISA's own FAQ for the platform independently states the identical clock
(ENISA, 2026-08-31).
The SRP became operational on 11 September 2026, the same date the reporting duty started to apply, and is reached
at portal.cra-srp.enisa.europa.eu through a personal EU Login account with multi-factor authentication
(ENISA, updated 2026-09-17).
NCSC-FI's checklist directs manufacturers to identify in-scope products now, noting that products past end-of-life
and no longer receiving updates remain subject to the reporting obligation, appoint an Assigned Representative (AR)
authorised to submit SRP notifications, document an internal report-intake and triage process, and rehearse it at
least once before the first reportable case
(NCSC-FI / Traficom, 2026-08-28).
ENISA's own FAQ states a manufacturer may register one Primary AR and up to 20 Secondary ARs, and that a
representative whose manufacturer association is not yet verified may still submit up to 20 notifications for that
manufacturer before verification becomes mandatory, so an organisation does not have to wait for verification to
complete before filing its first report under time pressure
(ENISA, updated 2026-09-17).
NCSC-FI's own checklist instead describes notifications as submittable only through two named representatives, a
narrower figure than ENISA's; the two authorities have not been reconciled, and ENISA's FAQ is treated as the more
current statement of the platform's own rules
(NCSC-FI / Traficom, 2026-08-28).
API-based submission is not expected until spring 2027 per NCSC-FI, and ENISA's own FAQ states only that "no
Application Programming Interface (API) will be provided at the initial release of the SRP" and that one may follow
in a later phase, without a target date,
so any automated vulnerability-management or SBOM-correlation pipeline still has to terminate at a manual web-portal
boundary for every notification filed before that changes
(NCSC-FI / Traficom, 2026-08-28;
ENISA, 2026-08-31).
The reporting duty is not limited to products launched after 11 September 2026: legal analysis of Article 69(3) CRA
confirms it applies from that date to every in-scope product already placed on the EU market
(Hogan Lovells Cadwalader, 2026-06-10),
and NCSC-FI's own checklist states products past end-of-life and no longer receiving updates remain subject to the
obligation regardless
(NCSC-FI / Traficom, 2026-08-28).
For an actively exploited vulnerability or a severe incident, an early warning must be submitted within 24 hours of the manufacturer becoming aware of it. The notification must be supplemented within 72 hours.
For a vulnerability, the final report must be submitted within 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final report must be submitted within one month of the incident notification.
Notifications are expected to be possible through APIs from spring 2027. After this, notifications can be submitted directly from the organisation's own system.
NCSC-FI / Traficom
The platform has become operational on 11 September 2026, coinciding with the date on which the CRA reporting obligations under Art.14 are applicable.
However, no Application Programming Interface (API) will be provided at the initial release of the SRP, so notifications must be submitted through the platform interface.
ARs whose manufacturer association has not yet been verified may submit up to 20 notifications for that manufacturer before verification becomes mandatory.
In the current release, the 72-hour counter displays a due date/time 48hrs after submission of the 24-hour Early Warning.
Notably, the reporting obligations apply from 11 September 2026 to all products with digital elements within the CRA's scope that have been made available on the EU market before full CRA application (Art. 69(3) CRA).
Hogan Lovells Cadwalader
As of 11 September 2026, manufacturers are required to report actively exploited vulnerabilities and severe incidents impacting the security of products with digital elements.
ENISA has established the CRA Single Reporting Platform (SRP), operational as of 11 September 2026.
Der Bitkom kritisiert insbesondere, dass Unternehmen die Meldeplattform vor deren Start nicht registrieren und die Prozesse nicht erproben konnten. Die Plattform ging erst mit Beginn der Meldepflicht online. (translated from German: Bitkom specifically criticizes that companies could not register on the reporting platform or test their processes before its start. The platform only went online with the start of the reporting obligation.)
ENISA's own Single Reporting Platform FAQ, updated 31 August 2026, now independently states the same 24-hour/
72-hour/14-day/1-month notification clock this entry previously sourced to NCSC-FI alone
(ENISA, 2026-08-31).
The Assigned Representative cap this entry previously described as "two" is corrected: ENISA's FAQ states a
manufacturer may register exactly one Primary AR and up to 20 Secondary ARs, and that a non-validated AR can submit
up to 20 notifications before validation becomes mandatory
(ENISA, 2026-08-31).
Eight days before the 11 September go-live, the platform still has no published URL and the FAQ confirms no API will
exist at launch, without stating a specific date for one; the spring-2027 API target remains NCSC-FI's own claim,
not independently corroborated
(ENISA, 2026-08-31).
Legal analysis of Article 69(3) CRA confirms the reporting duty applies from 11 September 2026 to every in-scope
product already on the EU market
(Hogan Lovells Cadwalader, 2026-06-10),
consistent with NCSC-FI's own checklist, which states products past end-of-life and no longer receiving updates
remain subject to the obligation regardless
(NCSC-FI / Traficom, 2026-08-28).
The SRP will be available in English only at launch
(ENISA, Single Reporting Platform (SRP) FAQ, 2026-08-31).
The obligation this entry has tracked ahead of go-live is now in legal effect: the European Commission's own page states plainly, "as of 11 September 2026, manufacturers are required to report actively exploited vulnerabilities and severe incidents impacting the security of products with digital elements"
(European Commission, 2026-07-31).
This covers every in-scope product already placed on the EU market before today, not only new ones, consistent with Article 69(3) CRA as this entry already recorded. Neither the Commission's page nor ENISA's own SRP page states that the platform is confirmed live and accepting submissions today; the Commission's page says only that "the Single Reporting Platform will be operational by 11 September 2026 (date of entry into application of the CRA reporting requirements)" and that "functional and security testing are under way"
(European Commission, 2026-07-31),
while ENISA's own SRP page states that "from 11 September 2026, manufacturers are required to submit these mandatory notifications through the SRP" without an explicit operational-status confirmation
(ENISA, 2026-09-10).
This entry therefore scopes its claim to what is independently confirmed (the legal reporting obligation is in effect) rather than to platform operational status, which no source reached has confirmed either way as of today.
The open point above is resolved: ENISA confirmed on 2026-09-11 that "the EU Agency for Cybersecurity (ENISA) has deployed the initial operating capability of the Single Reporting Platform (SRP)"
(ENISA, 2026-09-11),
manufacturers and, from 11 December 2027, open-source software stewards submit once through the platform and the receiving CSIRT disseminates the notification to every other Member State CSIRT where the affected product is available, simultaneously to ENISA.
A Bitkom survey of 1,003 German firms, relayed the same day by heise online, found only 29% know what the CRA means for their own organization and a further 38% have heard of it but cannot assess the impact; Bitkom specifically criticizes that manufacturers could not register on the platform or test their reporting process before today, "because the platform only went online with the start of the reporting obligation" (translated from German)
(heise online, 2026-09-11).
For a Swiss manufacturer or distributor placing networked products on the EU market, or a Swiss public-sector body procuring from an EU-regulated manufacturer now subject to this clock, the practical takeaway is that the 24-hour/72-hour/14-day-or-1-month reporting chain is a live obligation rather than a target date, and a first submission may hit friction precisely because pre-launch registration and testing were not possible.
The European Commission's own CRA reporting page now also confirms the launch: "ENISA has established the CRA Single Reporting Platform (SRP), operational as of 11 September 2026" (European Commission, updated 2026-09-11). The page previously gave 11 September 2026 as the target date with testing under way, which is the wording quoted in the 2026-09-11 section above.
ENISA's FAQ, revised on 17 September, now also answers the questions this entry left open before launch. The platform is at portal.cra-srp.enisa.europa.eu and each Assigned Representative signs in with a personal EU Login account with multi-factor authentication. No API exists at the initial release, and ENISA says only that one may be considered in a future phase. One operational detail matters for the reporting clock: "In the current release, the 72-hour counter displays a due date/time 48hrs after submission of the 24-hour Early Warning", so the platform can mark a notification overdue before 72 hours have passed since the manufacturer became aware. ENISA says a later release will count from the awareness time instead (ENISA, updated 2026-09-17).
VulnCheck published a follow-up on 2026-08-27 tracing the ZBT/Zbtlink supply chain further and finding two more pre-installed implants: DARKLANTERN, an unauthenticated WAN-listening command backdoor on UDP/9992 reachable by design through the router's own default firewall rules, and SPEAKINGSTONE, a phone-home implant beaconing to ZBT's own Alibaba Cloud infrastructure over UDP/10000. VulnCheck's internet scan found 203 DARKLANTERN-responsive devices across 22 countries between 18-21 August, and sinkholed SPEAKINGSTONE's abandoned backup domain to capture 392 beacons, 390 of them from China and 83% on China Mobile's network, evidence VulnCheck reads as a domestic Chinese surveillance deployment running the same firmware lineage sold to Americans through Amazon. Supply-chain tracing extends the confirmed OEM-rebrand list to Germany (Digineo AC1200 Pro, ALLNET ALL-WR1200AC-WRT) alongside existing US, Canadian and Australian rebrands, though VulnCheck is explicit that not every rebrand is confirmed to carry the same implants. No CVE has been assigned to either new implant; the follow-up post does not itself restate remediation guidance, so the original ENDLESSDOORS device-replacement guidance remains the only position on record.
VulnCheck traced the ZBT/Zbtlink supply chain further and published two additional pre-installed implants on the
same platform family (VulnCheck, 2026-08-27).
DARKLANTERN runs as the service infosrvd on UDP/9992, a port the router's default firewall explicitly opens to
the internet; an unauthenticated 19-byte probe returns the device's model, firmware, MAC address, SSID and public
IP, and a command packet passes an operator-supplied string directly to system(), where a semicolon breaks out of
the fixed command prefix into arbitrary root shell execution with no length limit or character filtering
(VulnCheck, 2026-08-27). The only gating fields are
a keyed checksum computed from a hardcoded static salt and a MAC-address check that is bypassed outright by sending
an all-zero MAC. VulnCheck's internet scanner found 203 DARKLANTERN-responsive devices across 22 countries between
18 and 21 August 2026, self-reporting across 16 different router models
(VulnCheck, 2026-08-27). SPEAKINGSTONE instead
beacons outbound over UDP/10000 to ZBT's own Alibaba Cloud infrastructure with a full device fingerprint, and
accepts plaintext, unauthenticated commands to run arbitrary shell commands, exfiltrate WAN PPPoE credentials,
write or read a DNS-hijack list, or open and close a reverse SSH tunnel; VulnCheck registered its abandoned
hardcoded backup domain and captured 392 beacons by 21 August, 390 from China, 83% on China Mobile's network, and
363 of them a single carrier-CPE model, which VulnCheck reads as a domestic Chinese surveillance deployment running
on the same firmware lineage sold to Americans through Amazon
(VulnCheck, 2026-08-27). Supply-chain tracing via
FCC filings, trademark records and archived web pages extends the confirmed OEM-rebrand list, previously US,
Canadian and Australian units (to Germany: Digineo's AC1200 Pro and ALLNET's ALL-WR1200AC-WRT) though VulnCheck is
explicit that it has not confirmed every rebrand carries the same implants
(VulnCheck, 2026-08-27). No CVE has been assigned to either new implant. The 2026-08-27 post does not restate VulnCheck's remediation
guidance or vendor-notification posture for DARKLANTERN/SPEAKINGSTONE specifically; VulnCheck's original ENDLESSDOORS
guidance, device replacement rather than a patch, and no notification to Zbtlink since there is no fix to
coordinate, remains its own position (VulnCheck, 2026-08-05).
Zbtlink has made a public statement of its own, announcing an intention "to suspend sales of affected routers and
take the affected software offline while updates are being worked on" (translated from German)
(heise, 2026-08-28). No update has
been published, and nothing in that statement covers DARKLANTERN or SPEAKINGSTONE, so device replacement and egress
control stay the operative guidance for deployed units.
Detection concept for the new implants: an unsolicited, long-lived, bidirectional command-carrying UDP channel from
consumer-class CPE to a fixed external host on a non-standard port (SPEAKINGSTONE's UDP/10000 beacon), or an
unauthenticated response to a 19-byte probe on UDP/9992 (DARKLANTERN), is not traffic ordinary router firmware
generates, egress/ingress telemetry at the site boundary surfaces this even for an unmanaged device. Triage:
routers legitimately make outbound connections for firmware checks, NTP and vendor telemetry, so outbound-from-CPE
alone is not a discriminator; the tell is the fixed vendor-independent destination and the bidirectional
command-carrying pattern, or an inbound-accepted session on 9992/8897 from an internet-routable source.
PaperCut has been targeted before: Rapid7 notes that in 2023 CVE-2023-27350 was broadly exploited in the wild by multiple threat-actor groups, including ransomware operators, which raises the urgency of this new zero-day (Rapid7, 2026-08-28). PaperCut disclosed on 27 August 2026 that it was investigating active exploitation of a new flaw in the same product line, before any CVE, patch or public technical detail existed (watchTowr, 2026-10-09); Rapid7 relays PaperCut's statement that information supplied by a university customer's security team and its digital forensics and incident response team enabled PaperCut to reproduce the vulnerability (Rapid7, 2026-08-28).
PaperCut's Application Server runs on the Apache Tapestry web framework, whose "complex direct" request format lets
a single HTTP request name one page to render and a different page's component to actually execute. PaperCut's own
authorization check validates only the page selected for rendering, not the component that runs behind it, so a
request that asks Tapestry to render the public, unauthenticated Error, Exception, or Home page while invoking the
administrative ConfigEditor or UserList component bypasses authentication entirely
(Rapid7, 2026-08-28).
Through three such POST requests, /app?service=direct/1/Error/ConfigEditor/quickFindForm,
.../ConfigEditor/$Form, and .../UserList/$QuickFind.$Form, an unauthenticated attacker rewrites four external
card/ID lookup settings (user-lookup.db-driver, user-lookup.db-url, user-lookup.id-to-username-sql,
user-lookup.enabled) that normally point PaperCut at an administrator-configured external card database
(Rapid7, 2026-08-28).
Redirected instead to an attacker-controlled JDBC target through PaperCut's bundled Apache Derby driver and its
foreignViews feature, the connection reaches an attacker-controlled H2 database whose inline INIT statement
creates a JavaScript-backed trigger; PaperCut's bundled Nashorn JavaScript engine then executes that trigger to
launch an operating-system process, full remote code execution as the PaperCut server, triggered the moment the
forged UserList search runs the malicious lookup
(Rapid7, 2026-08-28).
This is a two-CVE chain: CVE-2026-81578 (CWE-306, missing authentication) is the pre-auth entry that gains write
access to the server configuration; CVE-2026-82078 (CWE-470, unsafe dynamic class loading) is the flaw that turns a
reconfigured database connection into arbitrary Java bytecode execution once that write access is held
(PaperCut Software, 2026-09-10).
PaperCut treats all versions of NG and MF as potentially affected (Rapid7, 2026-08-28). Huntress observed two live customer
exploitations: one on 26 August lasting under two minutes against version 25.0.10.75465, and a second on 27 August
against version 24.1.5.71847, before Emergency Patch Release 2 extended coverage to the v24 line
(Huntress, 2026-08-28). In both cases the attacker ran
base64-encoded discovery commands (whoami & ver, and separately whoami & ver & tasklist) via a dropped,
OS-agnostic Java .class file; in the first incident it wrote its output to a temporary file and then deleted both that file and the
server's own server.log
(Huntress, 2026-08-28). Huntress's own proof-of-concept
reproduced the full chain against a stock PaperCut NG install and observed the code execution surface as an
observable charmap.exe process running as SYSTEM, spawned under the PaperCut Application Server's own pc-app.exe
process
(Huntress, 2026-08-28). PaperCut released an initial emergency patch for v25 and v26 on 28 August and patches for v24 later the same day, and Rapid7 says the first patch could be bypassed by using the Home page for display while the newest version of the vendor patch remediates that bypass (Rapid7, 2026-08-28). PaperCut then superseded the earlier emergency patches with Emergency Patch Release 3 on 1 September 2026 and replaced all three emergency patches on 10 September with fully tested maintenance releases (see the updates below) (PaperCut Software, 2026-09-10).
There is no fix for v23 and earlier; PaperCut's guidance for that line is to upgrade to a supported version (PaperCut Software, 2026-09-10), and
Huntress estimated on 28 August that 47% of the roughly 2,500 PaperCut installations it tracks ran v23 or older
(Huntress, 2026-08-28).
Detection, telemetry class first: alert on any child process spawned from pc-app.exe or the PaperCut Application
Server's Java process, the lineage under which the observed exploitation ran its discovery commands. Web-access logs for the PaperCut Application Server should
be checked for POST requests from an unauthenticated session whose service parameter puts a non-administrative page
in front of the ConfigEditor or UserList component, such as /app?service=direct/1/LogonMessage/ConfigEditor/quickFindForm,
because PaperCut checks authorization only for that first page (watchTowr, 2026-10-09); the Error and Home
variants described above follow the same shape, so the signal is the page in front of the component, not the component.
Two log artifacts are near-unique indicators: a server.logDB URL: line pointing at an in-memory Derby database, and a
corresponding derby.log entry recording Derby booting an in-memory database under an attacker-chosen name
(Huntress, 2026-08-28). PaperCut stresses that the absence of its file artifacts does not rule out compromise because the attacker may clean them up (PaperCut Software, 2026-09-10), and Huntress observed the payload deleting the server's own server.log (Huntress, 2026-08-28).
Requests to /rpc/api/xmlrpc that call api.setConfigValue or api.lookUpUserNameByCardNo from addresses outside the allowlist match the XML-RPC route, and Hunt.io advises disabling the endpoint where it is not needed (Hunt.io, 2026-10-15). Hunt.io's recovered kit also adds changes to the user-lookup.* settings, unexpected files under custom/web/, and chisel or cron entries calling out to non-standard ports (Hunt.io, 2026-10-15).
The later authentication bypass that watchTowr documents reaches the Setup Wizard pages through the Home page, so requests whose service parameter routes through Home to a setup page such as SetupAdmin on a server whose setup is long complete are the matching pattern (watchTowr, 2026-10-09).
Triage: an unexpectedly truncated, gapped, or missing server.log on a PaperCut Application Server is worth
investigating even where no other artifact survives, since Huntress saw the payload delete that log.
PaperCut Software security response team is investigating active exploitation of a vulnerability affecting PaperCut NG and PaperCut MF.
PaperCut Software
PaperCut's authorization check could trust the rendered page and miss the permissions required by the component behind it.
By selecting either the public Error page or Exception page for display, an attacker can bypass authentication while invoking administrative components belonging to ConfigEditor or UserList.
PaperCut has been targeted in the past; in 2023, CVE-2023-27350 was broadly exploited in the wild by multiple threat-actor groups, including ransomware operators.
Emergency Patch (Release 3) has been released by our emergency response team and supersedes Release 2. You do not need to install previous patches, this patch is an accumulation of all emergency releases. This release addresses two known regressions and adds additional hardening and mitigation against potential attack chains.
Servers that remain publicly reachable and unpatched continue to be targeted, and post-compromise behaviour observed in the second wave has been more sophisticated than in the first days of this incident.
These releases replace the emergency patches. If you are running an emergency patch build, move to a maintenance release. If you have not yet patched, upgrade now.
PaperCut Software
compromise at least 440 instances of PaperCut MF/NG hosted by 395 identified victim organizations in 48 countries
GreyNoise observed the adversary achieved domain admin against only 12 victim organizations.
If you have already upgraded to the latest release (26.0.5, 25.0.13, 24.1.11) the issues are already addressed.
PaperCut Software
The exposed tooling revealed a second PaperCut RCE path through XML-RPC, using api.setConfigValue and api.lookUpUserNameByCardNo when API access controls were weak.
A PaperCut instance that has already been hardened against the Tapestry bypass is not necessarily protected against this one if its XML-RPC API is exposed with weak access controls.
The remaining targets were spread across South Africa, Spain, Sweden, Saudi Arabia, Puerto Rico, Malaysia, Ireland, Chile, Switzerland, and Canada.
PaperCut's Emergency Patch Release 3, published 1 September 2026, supersedes Release 2 and is cumulative, customers
do not need to install the earlier releases first
(PaperCut Software, 2026-09-02).
Release 3 addresses two known regressions, fixing broken SAML login flows and restoring support for
legacy Microsoft SQL Server drivers used for external card lookup, and adds further, undisclosed hardening against
the exploitation chain
(PaperCut Software, 2026-09-02).
PaperCut also confirms a second wave of attacks against servers that remain unpatched and internet-facing, whose
post-compromise behaviour "has been more sophisticated than in the first days of this incident"
(PaperCut Software, 2026-09-02).
The vendor's own incident data, published 30 August as additional indicators of compromise, names a concrete
follow-on chain from the original intrusion: after initial discovery commands, a PowerShell-delivered download
installs a Windows service literally named "Remote Access Service" running SimpleService.exe, a SimpleHelp
remote-access agent, as LocalSystem with auto-start, followed by a further download of AnyDesk; the bulletin does
not state whether this specific chain recurred in the second wave or belongs only to the earlier intrusions it was
published alongside
(PaperCut Software, 2026-09-02).
Mobility Print and Print Deploy server components are unaffected; Site Servers and secondary/print servers do need
the same update as the primary Application Server
(PaperCut Software, 2026-09-02).
GreyNoise's Global Observation Grid documents an AI-agent-orchestrated exploitation campaign against this chain
beginning 31 August 2026, run by a likely Russian-speaking operator already tracked since July 2026 for attacks on
Palo Alto, Ubiquiti, Citrix, SonicWall and Proxmox VE targets
(GreyNoise, 2026-09-09). The
operator built and tested both CVEs' exploits in a self-hosted PaperCut/Active Directory lab, sourced target lists
via the Netlas.io scanning service, then deployed hundreds of AI agents, built on OpenAI's Codex harness paired
with a DeepSeek model, to opportunistically "compromise at least 440 instances of PaperCut MF/NG hosted by 395
identified victim organizations in 48 countries"
(GreyNoise, 2026-09-09). GreyNoise
reports the adversary "went from an empty workspace to first achieving RCE against a real victim in just under
four hours, first domain admin in an additional two hours, and once the full campaign launched, compromised at
least 11 organizations in 26 seconds"
(GreyNoise, 2026-09-09), with one
US high school reaching full domain admin in seven minutes from initial access. At its last observation, GreyNoise
had seen domain admin reached against only twelve victim organizations, "GreyNoise observed the adversary achieved domain admin
against only 12 victim organizations"
(GreyNoise, 2026-09-09), via three
paths: LSASS credential harvesting for pass-the-hash against the domain controller when the PaperCut host was
domain-joined; the 2021 noPac flaws (CVE-2021-42278/CVE-2021-42287) where those remained unpatched; or directly
adding a new account to Domain Admins when the PaperCut host itself ran on the domain controller or under a
domain-admin service account. All three paths finished with a DCSync-based full NTDS.DIT credential dump; Cloudflare's
WAF defeated the adversary against at least one targeted instance. This delta is reported by GreyNoise alone; a
second independent source had not corroborated it as of this update.
PaperCut published security maintenance releases 26.0.5, 25.0.13 and 24.1.10 for NG and MF on 10 September 2026. Unlike the emergency patches, they went through the vendor's full release testing, carry new version numbers and release notes, and address all the CVEs in the advisory with the same protection as the emergency patches plus additional hardening. PaperCut's instruction is plain: "These releases replace the emergency patches. If you are running an emergency patch build, move to a maintenance release. If you have not yet patched, upgrade now." A server already on Emergency Patch Release 3 is protected against both CVEs and can schedule the upgrade through normal change control, while one still on Release 1 or 2 should move now. Site Servers and secondary/print servers should be updated to a patched version, not just the primary Application Server (PaperCut Software, 2026-09-10).
Nothing changes for v23 and earlier: there is no emergency patch or maintenance release for that line, and the only route to a fixed build is an upgrade to a supported line (24, 25 or 26), with web access to the Application Server restricted to trusted addresses until then. PaperCut also reports that new compromises have slowed considerably and that most customers now have the Application Server behind a firewall or on a patched build, but that publicly reachable, unpatched servers are still being targeted (PaperCut Software, 2026-09-10). For an estate that patched in the first week, the task is to move each server from its emergency build to the maintenance release and confirm the version on every Site Server and secondary server, not only on the primary. CISA added both CVEs to its Known Exploited Vulnerabilities catalog on 2026-08-31 (CISA KEV).
watchTowr Labs published a write-up on 2026-10-09 that follows the emergency patches build by build (watchTowr, 2026-10-09). Its timeline: the patch released on 28 August (26.0.4-PO build 76508) fixed two bypasses watchTowr had reported; watchTowr then bypassed the fix for the authentication bypass again (tracked internally as WT-2026-0143, no CVE assigned) and found a new post-authentication code-execution flaw in Scan-to-Fax (WT-2026-0144, now CVE-2026-82077), which together gave a full unauthenticated chain against build 76508; the patch released on 1 September (build 76530) fixes WT-2026-0143, and 26.0.5, released on 10 September, fixes CVE-2026-82077 (watchTowr, 2026-10-09). The authentication bypass abuses the Setup Wizard forms, which the earlier patches had ignored: every stage can be reached through the Home page even after setup is complete, and watchTowr shows it modifies the administrator password (watchTowr, 2026-10-09). watchTowr also publishes a Detection Artefact Generator that tests a server's exposure to the authentication bypasses but does not run the full chain (watchTowr, 2026-10-09).
PaperCut's September security bulletin lists CVE-2026-82077 as a code-execution flaw in the Scan-to-Fax component that needs an authenticated administrator, rated CVSS 4.0 7.3, fixed in 26.0.5 and 25.0.13, and says servers already on the latest release are covered (PaperCut Software, 2026-09-24); in that text it named no 24.x release and no emergency build, and its revision of 2026-10-13 lists 24.1.10 for the 24.x branch (see the update of 2026-10-17). The unauthenticated chain watchTowr describes is closed by the 1 September patch, but an administrator-level foothold still reaches code execution through Scan-to-Fax until the maintenance release is installed. No source names exploitation of CVE-2026-82077 or of the Setup Wizard bypass. PaperCut says Emergency Patch Release 3 closes off additional attack vectors it has observed being exploited in the wild, without naming them (PaperCut Software, 2026-09-10).
Hunt.io found three open directories on one attacker host and reconstructs the operator's toolkit from the files in them; it says the recovered material aligns with GreyNoise's published account of the AI-driven campaign (Hunt.io, 2026-10-15). The operator's notes record a second route to code execution that does not use the Tapestry bypass: PaperCut's XML-RPC API at /rpc/api/xmlrpc accepts api.setConfigValue when its network allowlist is too permissive or no explicit API token is configured, because the handler then falls back to the built-in admin password as the token, and the same user-lookup settings are then rewritten (Hunt.io, 2026-10-15). Hunt.io says an instance already hardened against the Tapestry bypass is not necessarily protected against this one if its XML-RPC API is exposed with weak access controls (Hunt.io, 2026-10-15); it does not report the route used against a victim. PaperCut's documentation says the API's authentication token should be defined in the advanced config key auth.webservices.auth-token and that the address allowlist can be set in the admin interface or through auth.webservices.allowed-addresses (PaperCut Software, 2026-01-30).
The files also show what follows a compromise. A Linux kit keeps a chisel reverse SOCKS5 client alive through cron entries (periodic and at reboot) and a watchdog script that checks the process (Hunt.io, 2026-10-15). The Windows playbook exports the SECURITY and SYSTEM registry hives from a compromised host to recover LSA secrets, the domain machine account's password among them, offline (Hunt.io, 2026-10-15). The scale comes from the actor's own files: a reconnaissance pool of 1,005 hosts in at least 45 countries (800 confirmed vulnerable and 205 flagged from version fingerprinting), 2,165 logged attempts, 46 Active Directory domains packaged as victim data and 45 targets with a live reverse SOCKS5 pivot at the time of capture (Hunt.io, 2026-10-15). Switzerland is among the countries listed for those 45 targets, with no sector or organisation named, and Hunt.io says it shared its findings and the victim data with the national CERTs of the affected countries (Hunt.io, 2026-10-15).
PaperCut's September security bulletin, last updated 2026-10-13, now lists CVE-2026-82077 as fixed in 24.1.10 on the 24.x branch as well as in 26.0.5 and 25.0.13, and recommends 26.0.5, 25.0.13 or 24.1.11 or later (PaperCut Software, 2026-09-24).
Four statements above are corrected. PaperCut's bulletin says Emergency Patch Release 3 "addresses two known regressions", broken SAML login and support for legacy Microsoft SQL Server drivers for external card lookup, without saying Release 2 introduced them, as the update of 2026-09-03 stated (PaperCut Software, 2026-09-10). The web-log hunt now covers requests that put a non-administrative page such as LogonMessage in front of the ConfigEditor component, the route watchTowr documents, since PaperCut checks authorization only for that first page; the earlier pattern listed only Error, Exception and Home and missed it (watchTowr, 2026-10-09). Huntress's estimate that 47% of the installations it tracks run v23 or older dates from 28 August (Huntress, 2026-08-28). GreyNoise counts twelve victim organizations where domain admin was reached as of its last observation, not as a final tally out of the 395 (GreyNoise, 2026-09-09). The detection text and the second action now describe the Derby artifact as an in-memory database under an attacker-chosen name, without printing the name itself, which is an indicator value (Huntress, 2026-08-28).
Upgrade every PaperCut NG/MF Application Server, Site Server and secondary/print server to the security maintenance release for its line (26.0.5, 25.0.13 or 24.1.11, the v24 build the September bulletin now names), starting with any still on Emergency Patch Release 1 or 2, because the emergency builds do not carry the fix for CVE-2026-82077, an administrator-only Scan-to-Fax code-execution flaw that the vendor's September bulletin lists as fixed in 26.0.5, 25.0.13 and 24.1.10; for v23 and earlier, immediately restrict the Application Server's web interface to trusted/internal IP addresses only; no patch exists for that line. On every server, patched or not, set the advanced config key auth.webservices.auth-token to a long random secret and limit auth.webservices.allowed-addresses to the hosts that call the XML-RPC API, because Hunt.io says an instance hardened against the Tapestry bypass is not necessarily protected against the XML-RPC route it recovered, which works when the allowlist is too permissive or no token is set.
Before patching or restarting an internet-facing server, preserve the server/logs directory and process tree; check server.log for the two vendor-documented error strings and for an unexplained gap or truncation, check server.log and derby.log for an in-memory Derby database booted under an attacker-chosen name, and hunt for a Windows service named "Remote Access Service" running SimpleService.exe (SimpleHelp) or an unexpected AnyDesk install, as PaperCut's own published incident data names both as an observed post-compromise access method.
Given GreyNoise's confirmed domain-admin escalation paths, verify no PaperCut Application Server is domain-joined with a privileged service account or hosted on a domain controller, and confirm domain controllers reachable from any PaperCut host are patched against the 2021 noPac flaws (CVE-2021-42278/CVE-2021-42287); GreyNoise reports the AI-orchestrated campaign reaching full domain admin through these paths in as little as five minutes after initial access.
Verify the installed build number on every Exchange server directly against the August 2026 fixed builds (KB5121573/74/75/76); do not rely on patch-cycle records showing the update was scheduled or pushed; German BSI telemetry shows most comparable on-prem Exchange operators have not actually applied it two weeks after release.
2026-08-29T0409Z-intel· Sonnet 5, session-configured value (no harness self-ID line or env var available to the main agent this run; see notes) · window 24 h · 7 entries published
Verification & coverage notes
Coverage window: standard (13.16 hours since the previous run, 2026-08-28T1500Z-audit; that record's own publish outcome is still recorded as pending on main, with its own explanatory note that it was an operator-interactive session with no automated publish step, not an operational failure, so no action taken here beyond noting it).
Published this run (7 new, 1 update, 1 deep dive, 1 critical):
2026-08-29/papercut-ng-mf-tapestry-request-confusion-preauth-rce (critical, deep dive), PaperCut NG/MF pre-auth RCE chain, actively exploited before a patch existed.
2026-08-29/servicenow-ai-platform-four-unauth-cvss10-flaws (high), three unauthenticated CVSS4.0 10.0 flaws plus a related sandbox escape.
2026-08-29/exchange-mrsproxy-auth-bypass-cve-2026-62911-poc (high), public exploit code for an Exchange MRSProxy relay flaw, MSRC rating unrevised.
2026-08-29/swiss-cantons-eautoindex-vehicle-registry-data-harvesting (high), six Swiss cantons, rate-limit bypass on public vehicle-registry lookups, extortion attempts.
2026-08-29/eu-cra-reporting-obligation-ncsc-fi-checklist (notable), NCSC-FI's operational CRA reporting-clock checklist ahead of the 11 September go-live.
2026-08-29/redc2-npm-supply-chain-redshell-linux-implant (notable), closes a coverage-backlog item open since 2026-08-22; TrendAI's vendor primary replaces the aggregator-only sourcing that blocked it.
2026-08-29/german-carriers-imei-leak-call-setup-signaling (high), BR/heise investigation, GSMA-confirmed device-fingerprinting leak in call setup.
Update on 2026-08-06/endlessdoors-zbtlink-router-factory-shipped-root-backdoor, two new pre-installed implants (DARKLANTERN, SPEAKINGSTONE), a domestic-China surveillance-deployment finding via sinkhole, and a German OEM-rebrand extension.
Borderline drops:
borderline-drop: Minea (Swiss ad-intelligence platform) 533K-profile breach claim, single Admiralty-C source (cyberattaque.org) reporting an unverified hacker claim; the outlet's own reporting doubts the data's currency (records stop in August 2024 despite a claimed August 2026 compromise), no victim confirmation, and the affected business (ad-intelligence/dropshipping SaaS) has no nexus to the profiled constituency's sectors. Dropped for insufficient verification, not held at low priority.
borderline-drop: Qare (French telemedicine) hacker disclosure claiming exposed patient photographs including children, single Admiralty-C source, no victim statement, no independent corroboration despite a search attempt. Sensitive subject matter argues for more caution, not less, absent a second source.
borderline-drop: Boston Scientific cybersecurity incident (global medtech manufacturer, three Irish/EU plants idled), genuinely clears the relevance bar on EU/healthcare nexus alone, but no source (including a named commentator quoted by Industrial Cyber) states any attacker behaviour, access vector, or mechanism; an incident entry needs a genuine, evidence-supported ATT&CK mapping, and none exists yet to compose one honestly. Logged in the coverage backlog for publication the moment a vector is disclosed, the same disposition already applied to the Berlin Landesnetz compromise.
Contradiction:2026-08-29/servicenow-ai-platform-four-unauth-cvss10-flaws, ServiceNow's own advisory classifies CVE-2026-18886 as a code-injection flaw in its AI Platform; The Hacker News, reporting on the same advisory, classifies it as an improper-access-control flaw in a system-configuration image-upload processor. A second, related disagreement on the same entry: ServiceNow's own prose describes CVE-2026-6876 as reachable by an "unauthenticated user," while the CVSS4.0 vector ServiceNow itself assigned to that CVE (per The Hacker News's reporting) specifies PR:L, low privileges required. The entry carries all of these readings, attributed to their respective source, with the vendor's own classification treated as authoritative for the frontmatter cves[] records.
Single-source items:2026-08-29/redc2-npm-supply-chain-redshell-linux-implant; TrendAI Research is the sole discloser; no independent lab has corroborated it. Update on 2026-08-06/endlessdoors-...; VulnCheck remains the sole discloser for both the original ENDLESSDOORS finding and this run's DARKLANTERN/SPEAKINGSTONE follow-up; heise's coverage is journalism relaying VulnCheck's research, not independent technical corroboration.
Verification loop: 8 iterations, every one independently spawned and cold-reading fresh from disk. Iterations 1-8 all returned NEEDS_FIXES; every truth- and editorial-class finding across all eight was remediated (a running per-fact citation-attribution defect was the dominant pattern, plus one classification recalibration each on the ServiceNow and PaperCut entries, three technique-mapping corrections, and one hallucinated-fact removal each on the ENDLESSDOORS update, the ServiceNow entry, and the Swiss-cantons entry). The loop reached its 8-iteration cap without a confirmed CLEAN; publishing anyway is the documented fail-open (never a blocking condition). Three low-confidence advisory items from iteration 8 remain as residuals, none rising to a confirmed defect: an ambiguous ENISA citation date on the EU-CRA entry, an unverifiable BSI CERT-Bund corroborating-source page on the ServiceNow entry not tied to any specific claim, and a stretch-case missing ATT&CK mapping for SPEAKINGSTONE's PPPoE-credential exfiltration on the ENDLESSDOORS update. verification_residual_count: 1 reflects iteration 8's final truth+editorial count (1+0).
Coverage-backlog re-check: all five previously-open rows re-gated on today's facts. Struck: the RedC2 npm row (published). Stayed open, untouched or lightly re-checked at low cost: Zurich District Court verdict (not due until 2026-09-10), Berlin Landesnetz (re-confirmed no vector named by any authority, seventh consecutive fire blocked on the same ground), Siemens S7 joint-advisory re-read (low priority, not re-probed), CVE-2026-16242 OpenShift/HyperShift (still out of window), the Keycloak Red Hat product-state correction (low priority, meta-fact only). One row added: Boston Scientific (see borderline-drops above).
Watchlist: no product or supplier watchlist configured for this deployment (config/org-profile.yaml); the product and supplier sweeps were no-ops as a result; the sector/region lens was applied in their place.
Coverage gaps: searchlight-cyber (Cookiebot consent wall defeats every transport); team-cymru, sans-ics (both resolve through an ad-tracking redirect returning only a 1×1 pixel); paradigm-shift-research (client-side SPA stub, no server-rendered content); inside-it.ch's "Insel Gruppe verschiebt Wechsel zu ServiceNow" article (403 on every transport, flagged as a lead, not corroborated, plausibly but not confirmably related to the ServiceNow CVEs published the same day); cisa-advisories, cisa-directives (reachable, but no in-window item on either listing); cert-pl (newest item just outside the 24h window).
Essential-coverage: no misses; all essential-tier sources were attempted and returned content (even where that content held no in-window item).