CyberSip™ — Issue 117 — August 26, 2026

Today's picture

CISA added Gitea CVE-2026-60004 to its Known Exploited Vulnerabilities catalog today with a federal deadline of August 28, citing active exploitation of the CVSS 9.8 code injection that lets an attacker with repository write access install an executable Git hook through the diffpatch API and run shell commands as the Gitea service account, with open user registration on default Gitea installations converting the write-access precondition into one that any visitor can satisfy by registering an account and creating a repository. Oracle WebLogic Server CVE-2026-21962, an improper access control vulnerability in Oracle HTTP Server and the WebLogic Server Proxy Plug-in, was added to CISA KEV on August 24 and described as widely exploited, with the patch available in Oracle's August 2026 Critical Patch Update. ReliaQuest confirmed that a ShinyHunters-linked social engineering attack on August 22 obtained one employee's Okta credentials and MFA approval through a fake single sign-on page, granting the attacker a brief view-only session on its identity dashboard before device trust requirements and session termination stopped the attack from reaching any applications, systems, or customer data.

Today's intelligence

3 items

01 CriticalGiteaCISA KEV

Gitea CVE-2026-60004 is confirmed exploited and on CISA KEV today: open registration turns a write-access code injection into one any visitor can trigger

The flaw is in the diffpatch API endpoint. An attacker with repository write access submits a crafted patch twice, installs a Git hook into the processing directory, and runs shell commands as the Gitea service account. On default Gitea installations, open registration means any visitor can create an account, create a repository, and satisfy the write-access requirement. A crypto-miner payload was deployed on the first confirmed victim. Deadline is August 28.

CVECVE-2026-60004
CVSS 9.8

KEV addedAugust 26, 2026
(today)

Fed deadlineAugust 28, 2026

Fixed inGitea 1.27.1
Released July 27

Payload observedCrypto-miner
via automated
scanner

Sources SecurityWeek The Hacker News

What happened

CISA added CVE-2026-60004 to its Known Exploited Vulnerabilities catalog on August 26, 2026, citing active exploitation and setting a federal remediation deadline of August 28. Gitea is a widely deployed open-source, self-hosted Git platform that provides version control, code review, CI/CD workflows, and team collaboration, written in Go and maintained as a community fork of Gogs. CVE-2026-60004 is a code injection vulnerability in Gitea's diffpatch API endpoint, which processes repository patches using underlying Git commands. An attacker with write access to any repository can submit a crafted patch to the endpoint twice: the first submission creates a temporary bare repository clone, and because the root of the clone serves as Git's directory, a file placed at hooks/post-index-change in the crafted patch becomes an active Git hook. When Git subsequently processes operations in that directory, the hook executes, running arbitrary shell commands with the privileges of the Gitea service account. The critical operational detail is that most Gitea installations ship with open user registration enabled by default, with no email confirmation and no CAPTCHA required. This converts the write-access precondition into one that any unauthenticated visitor can satisfy in seconds: register an account, create a repository, and submit the exploit. Gitea patched the flaw in version 1.27.1, released July 27, 2026. A public proof-of-concept was included in the July 28 advisory. The first confirmed exploitation is documented in an incident report by a developer published on the Russian collaborative blog Habr. An automated scanner registered an account on the victim's Gitea instance, created a repository, and triggered the exploit chain. The payload wrote a proof of RCE into a Git branch, then downloaded a shell loader and then a cryptocurrency miner that contested for CPU resources. Because the Gitea instance ran in Docker without a privileged container configuration, the miner payload did not survive container restarts. The attack timeline from the Habr report is approximately 30 days after the patch was available, consistent with an automated scanner that indexed the vulnerability after the CVE was published.

Why it matters

Gitea is used by developer teams, small enterprises, and government organizations as a self-hosted alternative to GitHub or GitLab. The source code, pipeline configurations, deploy keys, secrets stored in repository environment variables, and CI/CD credentials in a Gitea instance represent the same class of assets that the LiteLLM supply chain attack targeted in March: the keys to downstream software distribution and infrastructure. Code execution as the Gitea service account gives an attacker access to every repository on the instance, every secret stored in those repositories, and every deploy key and CI/CD credential configured in the system. The cryptocurrency miner in the first confirmed incident is the opportunistic payload; a more targeted attacker with the same access would extract credentials, inject code into repositories, or modify pipeline configurations to introduce malicious components into software that downstream users build or deploy from the affected Gitea instance.

Don't miss

This is the second Gitea vulnerability on CISA KEV in two months. CVE-2026-20896, a different Gitea flaw, was exploited in early July and has not yet been added to the KEV catalog. The pattern of two separate Gitea vulnerabilities attracting in-the-wild exploitation within a two-month period reflects both the growth of Gitea as a deployment platform and the consistent attacker interest in self-hosted development infrastructure documented across GitLab CVE-2026-19478, the LiteLLM Trivy chain, and the Gitea KEV history. Organizations running self-hosted Gitea that have not already updated to 1.27.1 should also disable open registration if it is not required for their use case. Open registration is the single configuration change that converts CVE-2026-60004 from a threat requiring insider access to a threat exploitable by any automated scanner that discovers the instance over the internet.

Potential actions

Update Gitea to version 1.27.1 or later immediately. The federal deadline is August 28. Gitea Cloud instances were upgraded automatically as of July 27. Self-hosted instances running any version from 1.17 through 1.27.0 are vulnerable. Confirm the current version in the Gitea admin panel under Site Administration, Gitea Version, or by running the gitea --version command on the host.
If immediate update is not possible, disable open user registration as an interim mitigation. In the Gitea admin panel, navigate to Site Administration, User Management, and disable the Allow Self-Registration setting. This removes the open-registration precondition that converts CVE-2026-60004 from a write-access exploit to one exploitable by any visitor. Any existing user with write access to a repository on an unpatched instance remains a risk; restrict repository write access to the minimum required accounts until the update is applied.
For Gitea instances that were internet-accessible before today and running a vulnerable version, review repository activity logs for unexpected account registrations, repository creations, or anomalous API calls to the diffpatch endpoint. Check running processes and container logs for cryptocurrency mining activity, unexpected outbound network connections, or new Git hook files in repository directories.

The Sip

Write access required. But open registration is on by default. Any visitor can register, create a repository, and run this exploit. An automated scanner found the first known victim and dropped a miner in 30 days. Update to 1.27.1. If you cannot update today, turn off open registration. Deadline is Friday.

02 HighOracle WebLogicCISA KEV

Oracle WebLogic CVE-2026-21962 is on CISA KEV and described as widely exploited, with the patch in August's Critical Patch Update

CVE-2026-21962 is an improper access control flaw in Oracle HTTP Server and the WebLogic Server Proxy Plug-in. Successful exploitation can enable unauthorized creation, deletion, modification, or access to all data accessible through the affected components. Widely exploited per SecurityWeek. Patch is available in the August 2026 Oracle CPU released August 19.

CVECVE-2026-21962

ComponentsOracle HTTP Server
WebLogic Proxy
Plug-in

KEV addedAugust 24, 2026

ExploitationWidely exploited
(SecurityWeek)

PatchAugust 2026 CPU
Released Aug 19

Sources SecurityWeek CISA KEV

What happened

CISA added CVE-2026-21962 to its Known Exploited Vulnerabilities catalog on August 24, 2026. The vulnerability is an improper access control issue affecting Oracle HTTP Server and the Oracle WebLogic Server Proxy Plug-in. Oracle HTTP Server is the web server component of Oracle's Fusion Middleware stack, and the WebLogic Proxy Plug-in is used to route HTTP requests from Oracle HTTP Server to WebLogic Server application clusters. Improper access control in these components can allow a remote attacker to perform unauthorized operations including creating, deleting, modifying, or accessing data that the affected component can reach, potentially extending to all data accessible through the WebLogic application layer. SecurityWeek described the flaw as widely exploited by threat actors against WebLogic servers. Oracle addressed the vulnerability in its August 2026 Critical Patch Update, released August 19, 2026, which this brief covered in Issue 112. That release addressed over 1,000 vulnerabilities across Oracle's product portfolio, with more than 460 remotely exploitable without authentication. The Oracle CPU also includes CVE-2026-60702, the CVSS 9.9 WebLogic Server remote takeover flaw covered in Issue 112. Organizations that applied the full August Oracle CPU on August 19 have already addressed CVE-2026-21962. Organizations that deferred Oracle patching are now operating with a known-exploited flaw in their WebLogic infrastructure.

Why it matters

WebLogic Server is the Java enterprise application server running business-critical applications at large enterprises, particularly in financial services, insurance, healthcare, and government sectors. The proxy plug-in that carries CVE-2026-21962 is the routing layer between the public-facing web server and the WebLogic application tier. Access control flaws in this component affect the boundary between externally accessible HTTP and the application layer behind it. The CISA KEV addition and SecurityWeek's characterization of widespread exploitation confirms the pattern this brief has documented throughout August: Oracle WebLogic critical vulnerability disclosures are followed by rapid exploitation, and the August CPU carries multiple critical items that were already moving toward weaponization before the patch release date.

Don't miss

Issue 112 noted that prior critical Oracle WebLogic flaws were exploited within days to weeks of disclosure based on the historical pattern. CVE-2026-21962 moved from Oracle CPU release on August 19 to CISA KEV on August 24, five days later. The timeline for this specific flaw was faster than the historical average. Organizations that applied the August Oracle CPU on the release date had a five-day window before confirmed widespread exploitation began. Organizations that have not yet applied the August CPU have been operating with a confirmed-exploited WebLogic vulnerability for five days. The Oracle CPU is a substantial update that requires planning and testing for Oracle environments; the CISA KEV addition is the indicator that the planning phase should have already concluded and execution should be underway.

Potential actions

Apply the August 2026 Oracle Critical Patch Update to Oracle HTTP Server and WebLogic Server environments immediately. CVE-2026-21962 is confirmed exploited and on CISA KEV. If the full August CPU has not been applied, treat the WebLogic Proxy Plug-in and HTTP Server patches as the first priority within the Oracle patching sequence.
Review Oracle HTTP Server and WebLogic access logs for anomalous request patterns to the proxy plug-in layer since August 19. Exploitation of access control flaws in the proxy tier can manifest as unexpected access to application paths, unusual HTTP method combinations, or requests to administrative endpoints that should not be externally accessible. CISA's forensics guidance for CVE-2026-21962 should be checked for any specific indicators published alongside the KEV entry.

The Sip

CPU released August 19. CISA KEV August 24. Widely exploited. Five days from patch to confirmed exploitation pattern in a product that has a documented history of rapid weaponization. Apply the August Oracle CPU. If it was already applied on August 19, the WebLogic environment is patched. If not, it is not.

03 HighReliaQuestShinyHunters

ShinyHunters bypassed ReliaQuest's MFA with a fake SSO page and got as far as one employee's identity dashboard before device trust stopped the attack

The attacker combined vishing, a lookalike domain at reliaquest.claims, and a cloned SSO page to get one employee's credentials and MFA approval. What stopped the attack from spreading was not catching the phish. It was that the identity platform required a device trust check that the attacker's session could not satisfy. The attack was stopped at the identity layer by a control that was not the MFA that was already bypassed.

Attack dateAugust 22, 2026

ActorShinyHunters
(claimed)

MethodVishing + lookalike
domain + fake SSO
+ MFA push abuse

Access obtainedView-only Okta
identity dashboard
one session only

Stopped byDevice trust check
required for app
access

Sources Help Net Security SecurityWeek

What happened

ReliaQuest, the managed security operations company behind the GreyMatter threat detection platform, confirmed on August 23, 2026, that one of its employees was targeted in a social engineering attack on August 22. The attack was later claimed by a group affiliated with ShinyHunters on its data leak site. The attack chain had five steps. First, the attackers registered the domain reliaquest.claims, using a naming convention that ReliaQuest's own threat research team had publicly documented one week earlier as a ShinyHunters campaign pattern: using the .claims top-level domain to construct lookalike domains for targeted companies. ReliaQuest had posted about this pattern on X on August 17 and then deleted the post. Second, the attackers called multiple ReliaQuest employees by phone, impersonating members of the company's internal security team, using the name of a real security employee to add credibility to the call. Third, one employee followed the caller's instructions and navigated to the lookalike domain, where they encountered a cloned version of ReliaQuest's Okta single sign-on page. Fourth, the employee entered their credentials into the fake page. Fifth, the attacker used those credentials to initiate an authentication request on the real Okta platform, which sent an MFA push notification to the employee's device. The employee approved the push. This gave the attacker a valid Okta session. From the identity dashboard, the attacker attempted to access ReliaQuest's connected applications. All application access attempts failed. ReliaQuest's Okta configuration requires that the accessing device be registered and trusted by the organization before application access is granted, regardless of valid credentials. The attacker's device was not registered. The session was terminated by ReliaQuest's security team after the intrusion was detected. The compromised account's password was reset and all authentication factors were revoked.

Why it matters

The ReliaQuest incident documents both what a sophisticated social engineering attack looks like against a security-aware target and precisely which control stopped it. What did not stop the attack: user awareness, the employee was a security professional at a security company; the MFA factor, it was approved by the employee; or the SSO platform credential check, valid credentials were entered. What did stop the attack: a device trust policy that required the accessing device to be a registered organizational device before applications could be reached. The identity dashboard itself was accessible from the unregistered device because viewing one's own identity dashboard is a session-level function. Application access required the additional device trust check, and that check could not be satisfied from a device the attacker controlled. The control that prevented impact was not a user behavior control or an authentication factor control. It was an authorization control that operated independently of whether valid credentials were presented.

Don't miss

ReliaQuest published a detailed technical incident analysis specifically to help other organizations understand the attack chain and the controls that limited its impact. The report notes two details that are operationally significant beyond this specific incident. First, the attacker used the name of a real ReliaQuest security employee during the vishing calls, which is consistent with ShinyHunters' documented practice of researching targets on LinkedIn and company websites before social engineering calls to make the caller seem legitimate. Second, ReliaQuest emphasizes in its own post-incident write-up: phishing works, even against trained security professionals. The lesson is not that security training is ineffective. The lesson is that device trust policies and conditional access controls that operate independently of credential validity are the controls that contain the damage when phishing does work, because phishing will eventually work against someone in any organization regardless of training quality.

Potential actions

Implement device trust requirements in your identity platform configuration for all application access, not only for high-sensitivity applications. The ReliaQuest attack was limited in impact because the attacker's unregistered device could not satisfy the device trust check required to access connected applications from the Okta dashboard. In Okta, this is implemented through device assurance policies. In Microsoft Entra ID, it is implemented through compliant device conditional access policies. Both require that the accessing device be enrolled in the organization's mobile device management solution before application access is granted.
Audit your organization's use of the .claims top-level domain as a monitoring signal. ShinyHunters has used the pattern of registering [company-name].claims domains for vishing and phishing campaigns targeting employees. Configure your threat intelligence monitoring to alert on newly registered domains that combine known company names or abbreviations with the .claims TLD, or work with your threat intelligence provider to add this pattern to brand protection monitoring.
Review your MFA configuration for push notification fatigue risk. The ReliaQuest employee approved the MFA push in the context of a convincing vishing call. Consider implementing number matching in MFA push notifications, where the employee must enter a number displayed on the authentication screen rather than simply approving a push, which significantly reduces the success rate of push approval attacks conducted during vishing calls.

The Sip

Security company. Security-trained employee. MFA in place. The attacker used the name of a real colleague and a convincing fake SSO page. The MFA push was approved. What stopped the damage was a device trust policy that a valid Okta session on an unregistered device could not satisfy. Phishing works. Device trust is the control that limits what happens after it works.

Cross-source standouts

Gitea and the open-registration amplifier: when a default setting converts a write-access precondition into an unauthenticated one

CVE-2026-60004's CVSS score of 9.8 reflects a flaw that is effectively unauthenticated on most deployments. The vulnerability requires repository write access as a technical precondition. But the most common Gitea deployment configuration, open registration enabled by default with no email confirmation and no CAPTCHA, means any visitor to the Gitea instance can create an account in seconds. Account creation gives write access to the account's own repositories. Write access to one's own repositories satisfies the write-access precondition for CVE-2026-60004. The practical difference between a vulnerability that requires authentication with existing credentials and one that requires authentication that any visitor can obtain by registering is minimal from a security standpoint, especially when exploitation is automated. The documented attack against the Habr developer's instance was conducted by an automated scanner that registered an account without human involvement. The operational lesson is that the precondition qualifier in a vulnerability's description, requiring authentication, or requiring write access, must always be read alongside the question of how easy that precondition is to satisfy. For Gitea with open registration, the answer is: trivially easy, in under a minute, without any prior relationship with the target. The configuration change that converts this from a near-unauthenticated attack to a genuinely write-access-gated one is turning off open registration. That change is available now, does not require a software update, and eliminates the amplifier regardless of whether the patch has been applied.

ReliaQuest, MFA fatigue, and the control hierarchy after a credential is stolen: what defense-in-depth looks like when it actually works

The ReliaQuest incident is notable because it was disclosed in detail by the victim, a security operations company that produces threat intelligence, and because it clearly identifies which control stopped the attack. Most breach disclosures describe what went wrong. This one describes what went wrong and what went right in terms specific enough to be actionable. The attack chain was textbook for ShinyHunters: vishing with real employee names, a lookalike domain, a cloned SSO page, MFA push approval during a call that made the approval seem legitimate. Every element of that chain has been documented across dozens of ShinyHunters and Scattered Spider incidents in 2025 and 2026. The attack succeeded at the credential and MFA layer. What it could not do was satisfy the device trust requirement for application access. Device trust, also called device compliance or conditional access in different platforms, is a requirement that the accessing device be enrolled in the organization's endpoint management solution before a valid identity session is permitted to reach connected applications. It is distinct from MFA: it is an authorization check, not an authentication check. An attacker can have valid credentials and a valid MFA-approved session and still be denied application access if the accessing device is not enrolled. This is the control that stopped the ReliaQuest attack from reaching any application, system, or customer data after credentials were stolen. It is also the control that is most commonly missing in organizations that deploy SSO and MFA but treat device trust as an advanced optional configuration rather than a baseline requirement.

Still watching

Days 2–5

ShieldBreak CVE-2026-69414 (Issue 113 · Defender patch bypass, patch in progress per August 21) — low privilege to SYSTEM on fully patched Windows 10, 11, and Server 2025. Monitor MSRC for the patch release and apply the day it ships. Verify endpoint detection is updated for CVE-2026-69414 specifically.

Day 7+

GitLab CVE-2026-19478 (Issue 111/114 · confirmed exploited, NSA/CISA joint advisory) — upgrade to 19.2.4, 19.1.6, 19.0.8, or 18.11.11. Hunt @gl_introduced in web server logs from August 17 onward. Versions 18.2 through 18.10 have no patch; restrict /api/graphql as interim control.

Day 7+

GeoServer zero-day (no CVE, no patch) (Issue 108 · active probing since August 12) — no patch as of August 26. Restrict public WFS endpoint access. Limit SQL Server backend permissions to block xp_cmdshell. Monitor jsonArrayContains filter logs for injection patterns.

Day 7+

M365 Copilot prompt injection (Issue 98 · Hakon Maloy, reported March 7, 2026) — no CVE, no complete patch, 172 days. Enterprise Copilot prompt injection path remains open. Scope Copilot connector access tightly. Treat Copilot memory as a potential persistence mechanism requiring periodic review.

Day 7+