[Security News] Fastjson and GitLab Flaws Draw Patch Push (7.25)

Security teams faced a mixed July 25 queue: active targeting of a Fastjson 1.x remote code execution flaw, public GitLab exploit code for unpatched…

Fastjson and GitLab Flaws Draw Patch Push (7.25)

Overview

Fastjson 1.x drew the highest patch priority after feeds.feedburner.com reported active targeting of CVE-2026-16723, an unauthenticated remote code execution flaw with an Alibaba-assigned CVSS score of 9.0.
GitLab administrators faced a narrower but immediate exposure window after researchers published PoC code for a flaw already patched on June 10, affecting unupdated self-managed 18.11.3 servers.
CTM360 described a shift in insurance phishing from delayed credential harvesting to faster account hijacking workflows that try to act while victims are still engaged.
PRODAFT’s reporting on DevMan showed how ransomware-as-a-service groups are using portal-style operations to manage payloads, victims, finance, and affiliate activity.

Details

Fastjson 1.x RCE Draws Active Targeting With CVSS 9.0

feeds.feedburner.com reported on July 25 that security firms ThreatBook and Imperva observed attacks targeting Fastjson 1.x, Alibaba’s JSON library for Java. The issue is tracked as CVE-2026-16723 and carries an Alibaba-assigned CVSS score of 9.0, putting it in the Critical range by ordinary operational triage standards.

The reported risk centers on affected Spring Boot applications. In those cases, a malicious JSON request can lead to remote code execution(RCE) without authentication, running with the privileges of the Java process. That combination matters because internet-facing Java services often process JSON by default, and unauthenticated RCE shortens the path from scanning to compromise.

The source material says no patch was available at publication time. That makes mitigation more important than a normal update cycle. Teams using Fastjson 1.x should first identify exposed applications, restrict inbound access where possible, review application logs for unusual JSON payload handling, and reduce process privileges so a successful exploit has less reach.

▸ Fastjson deep dive

Fastjson has long been a sensitive dependency because JSON parsers sit close to application input. When a parser bug reaches code execution, the vulnerable component is not a peripheral tool; it is often part of the request path. In a Spring Boot deployment, that can place the vulnerable code behind public API routes, internal service endpoints, or administrative integrations that were never treated as a direct shell-equivalent risk.

The key operational point is the privilege boundary. The report says code can run with the privileges of the Java process. If that process owns application secrets, database credentials, local files, or cloud metadata access, the compromise can move beyond the original request handler. A lower-privilege service account, stronger outbound filtering, and tighter secret scoping reduce the damage even before a vendor fix exists.

Because the available source data describes active targeting but does not provide a patched version, defenders should avoid waiting for a neat version-number answer. The practical sequence is inventory first, exposure reduction second, detection third. Asset teams should search for Fastjson 1.x in build files, container images, software bills of materials, and shaded Java archives. Security teams should pair that search with web telemetry for Spring Boot endpoints receiving unusual JSON bodies.

This is also a case where exploit details add little value for a general briefing. The defensive question is whether any Fastjson 1.x code path accepts untrusted JSON. If it does, the application belongs in the emergency queue until a vendor patch, a safe upgrade path, or a compensating control removes that reachable path.

Key takeaway: CVE-2026-16723 should be treated as an urgent exposure-management issue, not just a library bug. Until a patch is available, access controls, dependency inventory, and process hardening carry the response.

GitLab PoC Raises Risk for Unpatched Self-Managed 18.11.3 Servers

feeds.feedburner.com reported that researchers at depthfirst published working exploit code on July 24 for a GitLab flaw that GitLab patched on June 10. The reported exposure applies to self-managed GitLab 18.11.3 servers that have not taken the update.

The flaw lets an authenticated user who can push to a project run commands as the git user. That is not the same as unauthenticated internet compromise, but it remains serious in organizations where many developers, contractors, automation accounts, or compromised credentials can push code.

The timing changes the risk calculus. A patch had already existed for about six weeks when the PoC appeared, so the defensive question is no longer whether a fix exists. It is whether self-managed instances actually applied it, and whether any lower-trust users had push access during the gap.

▸ GitLab PoC deep dive

Public PoC publication often changes a vulnerability from a theoretical backlog item into an operational race. Before exploit code appears, some organizations rank the issue behind externally exploitable bugs or internet-facing appliances. After publication, the barrier drops for attackers who already have credentials, access to a project, or a foothold in a developer environment.

The reported requirement for authentication gives defenders a meaningful boundary, but it should not create complacency. Source-code platforms are high-value systems. They hold proprietary code, deployment scripts, CI secrets, package credentials, and release workflows. Command execution as the git user may allow an attacker to inspect repositories, tamper with build paths, or look for credentials stored in project history and automation configuration.

The affected version detail is useful because it gives administrators a crisp starting point: self-managed 18.11.3 servers that missed the June 10 update. Managed SaaS exposure is not established by the supplied source data, so the response should focus on self-hosted instances. Administrators should confirm the deployed version, apply GitLab’s fixed release if they have not already done so, and review project access for accounts with push rights.

Detection should look beyond one exploit path. Teams should check for unusual commits, suspicious notebook files, unexpected diff views, and abnormal commands or child processes associated with the git service account. If the instance supports critical release workflows, incident responders should also review recent pipeline tokens, deploy keys, and protected branch settings. The goal is to determine whether the server was only vulnerable or was actually used as a stepping stone.

Key takeaway: The GitLab issue is most urgent for self-managed servers that skipped the June 10 patch. Public PoC code makes access review and post-patch log inspection part of the response, not optional cleanup.

CTM360 Says Insurance Phishing Is Moving Toward Real-Time Hijacking

feeds.feedburner.com reported that CTM360 research found insurance-focused phishing operations adopting a more immediate account-takeover model. Older campaigns often collected usernames and passwords for later use. The newer pattern tries to act while the victim is still in the session.

That shift matters because many defensive controls assume time exists between credential theft and account abuse. Password resets, suspicious-login review, and manual fraud checks work best when attackers wait. Real-time workflows compress that window and can force defenders to rely more on session controls, transaction checks, and phishing-resistant authentication.

The source data does not name a CVE because this is campaign research rather than a software vulnerability. The affected surface is the human login path around insurance and financial services accounts. The mitigation is therefore procedural and architectural: reduce reliance on passwords, monitor account changes in-session, and challenge high-risk actions with stronger proof.

▸ Insurance phishing deep dive

Insurance accounts are attractive because they sit at the intersection of identity data, payment details, claims information, and trusted communications. A successful login may expose enough personal information to support fraud elsewhere. It may also let attackers redirect communications or manipulate policy and claims workflows, depending on the portal.

The reported move from harvesting to real-time hijacking reflects a broader adaptation in phishing. Attackers increasingly design campaigns around the controls defenders actually use. If a bank or insurer flags a login only after credentials appear from a new location, attackers can try to complete the most valuable action before review begins. If a one-time code is required, the phishing flow can pressure the victim to enter it immediately.

For defenders, the lesson is to measure account risk at the action level, not only at login. A session that begins with valid credentials can still become risky when it changes contact details, adds a payout method, downloads sensitive documents, or triggers a claims-related workflow. Those actions deserve separate checks, especially when device, location, or behavior signals do not match the account’s history.

User guidance also has to be precise. Telling customers to “watch for phishing” is too broad. Better controls include passkeys where available, alerts for profile changes, short-lived sessions for sensitive actions, and clear recovery paths when customers report a suspicious login. Security teams should also coordinate with fraud teams because the first sign of compromise may appear as an abnormal business action rather than a malware alert.

Key takeaway: CTM360’s finding points to a faster phishing model aimed at using access immediately. Insurers and financial services teams should protect sensitive account actions, not only the initial sign-in screen.

DevMan Portal Shows RaaS Operations Becoming More Centralized

feeds.feedburner.com reported that the operators of DevMan ransomware-as-a-service maintain a dedicated web platform for affiliates. The portal reportedly supports payload building, earnings oversight, victim management, and related operational functions.

Swiss cybersecurity company PRODAFT tracks the centrally administered operation under the name Funky Mantis. The reporting describes a service model rather than a single intrusion. That distinction matters because a portal can make ransomware operations more repeatable for affiliates who do not build every tool themselves.

There is no CVE tied to this item in the supplied data. The immediate relevance for defenders is threat operations: ransomware groups continue to professionalize the business layer around intrusions, extortion, payments, and affiliate coordination. That means prevention still depends on basic controls, but response planning must account for faster handoffs after initial access.

▸ DevMan RaaS deep dive

Ransomware-as-a-service lowers the skill required to participate in extortion. A centralized portal can package tasks that once required separate tooling: generating payloads, tracking victims, monitoring payments, and allocating affiliate shares. That structure can improve consistency across attacks and reduce friction for operators who specialize in access, negotiation, or deployment.

For enterprise defenders, the portal detail matters less as a brand name and more as a reminder of workflow speed. Once an affiliate has access, a mature service platform can help turn that access into encryption, theft, or extortion more quickly. The best defensive value therefore comes from breaking the chain early: hardened remote access, patched edge systems, monitored identity providers, least-privilege administration, and tested backup restoration.

The affiliate model also complicates attribution. A victim may see tactics from one intrusion partner, infrastructure linked to another, and branding from the central ransomware program. Security teams should avoid overfitting defenses to a single group name. Mapping behaviors such as credential abuse, lateral movement, data staging, and backup interference gives incident responders a more durable playbook.

This report also supports a practical tabletop scenario. Organizations should ask how quickly they can detect mass file access, unusual archive creation, disabled security tools, or new administrator activity. They should also confirm who can make legal, communications, and recovery decisions during an extortion event. RaaS groups exploit operational delay as much as technical weakness.

Key takeaway: DevMan’s portal model shows ransomware operations continuing to standardize affiliate work. Defenders should focus on slowing the intrusion chain and rehearsing decisions before extortion pressure begins.

Morning Breaking Updates

feeds.feedburner.com: Malvertising Sends Malware in Pieces, Then Makes the Browser Build the Executable - A malvertising operation dubbed SourTrade is making victims' browsers build the final Windows executable themselves, using a legitimate Bun runtime as its base instead of serving o

▸ More — additional context and sources

BlueNoroff Zoom Phishing Kit Profiles Crypto Wallets Before Malware Delivery

Reported by feeds.feedburner.com. The North Korean threat actors behind the ClickFix-style campaigns that employ typosquatted Zoom and Microsoft Teams domains have been foun…

At a glance

Fact	Publisher	Source
Fastjson 1.x flaw is tracked as CVE-2026-16723 with CVSS 9.0.	feeds.feedburner.com	thehackernews.com
Affected Spring Boot apps may allow unauthenticated remote code execution.	feeds.feedburner.com	thehackernews.com
GitLab patched the reported flaw on June 10; PoC code appeared July 24.	feeds.feedburner.com	thehackernews.com
Self-managed GitLab 18.11.3 servers are exposed if they missed the update.	feeds.feedburner.com	thehackernews.com
CTM360 described insurance phishing that moves toward real-time account takeover.	feeds.feedburner.com	thehackernews.com
PRODAFT tracks the DevMan RaaS operation under the name Funky Mantis.	feeds.feedburner.com	thehackernews.com

FAQ

Q1. What is the most urgent vulnerability in this briefing?

A. CVE-2026-16723 in Fastjson 1.x carries the clearest emergency signal because feeds.feedburner.com reported active targeting and an Alibaba-assigned CVSS score of 9.0. The exposed condition is unauthenticated remote code execution in affected Spring Boot applications.

Q2. Which systems are affected by the GitLab PoC report?

A. The supplied report names self-managed GitLab 18.11.3 servers that did not apply the June 10 patch. feeds.feedburner.com said exploitation requires an authenticated user with push access, so administrators should review both version status and project permissions.

Q3. Why does the CTM360 phishing report matter if there is no CVE?

A. CTM360’s research, as carried by feeds.feedburner.com, describes a campaign behavior change rather than a software flaw. Real-time account hijacking reduces the usefulness of delayed credential-response workflows and puts more weight on session monitoring and action-level checks.

Q4. How is the DevMan report different from a normal ransomware alert?

A. PRODAFT, cited by feeds.feedburner.com, tracks DevMan as Funky Mantis and describes a portal that centralizes payload builds, victim management, finance, and affiliate activity. That points to operating infrastructure, not only one malware sample.

Q5. What should security teams watch after July 25?

A. Watch for a Fastjson 1.x patch or vendor mitigation, GitLab scanning against unpatched self-managed 18.11.3 servers, and follow-up reporting from CTM360 and PRODAFT. The highest-value signal is confirmed exploitation against systems matching these conditions.

Sources

Last updated: 2026-07-26T04:20:08.308Z

Mini-Step

이 블로그 검색