GitLab security update – patch for XSS vulnerability in file rendering
(TLP: CLEAR) GitLab has released critical security updates for its Community Edition (CE) and Enterprise Edition (EE), addressing multiple vulnerabilities, including a high-severity cross-site scripting (XSS) flaw. The patched versions—17.8.1, 17.7.3, and 17.6.4—are now available, and GitLab strongly recommends that all self-managed installations upgrade immediately. The most critical vulnerability, CVE-2025-0314, is a stored XSS flaw caused by improper rendering of certain file types using Asciidoctor. With a CVSS score of 8.7, this flaw allows attackers to inject malicious scripts into GitLab instances, potentially leading to session hijacking, data theft, or system compromise. The vulnerability was responsibly disclosed via GitLab’s HackerOne bug bounty program. Another issue, CVE-2024-11931, is a medium-severity flaw (CVSS: 6.4) that could enable CI/CD variable exfiltration under specific conditions using the CI lint feature. Additionally, a denial-of-service (DoS) vulnerability (CVE-2024-6324, CVSS: 4.3) was identified, allowing attackers to exhaust system resources by creating cyclic references between epics. To mitigate these risks, GitLab urges all users to upgrade to the latest versions and adopt security best practices, such as regular updates, log monitoring, user education on phishing risks, prompt application of patches, and periodic security audits.
(TLP: CLEAR) Comments: Malicious actors can exploit Asciidoctor’s integration with GitLab by injecting harmful content into .adoc files, leveraging features such as macros, includes, and external links to execute attacks. Since Asciidoctor allows inline macros and remote file inclusion, an attacker could craft a malicious AsciiDoc file that, when rendered, loads external scripts or phishing content. In GitLab repositories or wikis, such files could be used to mislead developers, manipulate documentation, or even execute Cross-Site Scripting (XSS) attacks if improper sanitization occurs. Additionally, if Asciidoctor is used in GitLab CI/CD pipelines, an attacker with repository access could manipulate .gitlab-ci.yml to execute unauthorized scripts, potentially leading to remote code execution (RCE). Organizations should implement strict validation, restrict Asciidoctor macros, and review repository permissions to mitigate such risks.
(TLP: CLEAR) Recommended best practices/regulations: PCI-DSS V4.0 Section 6.4.2: “For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following:
- Is installed in front of public-facing web applications and is configured to detect and prevent web-based attacks.
- Actively running and up to date as applicable.
- Generating audit logs.
- Configured to either block web-based attacks or generate an alert that is immediately investigated.
(TLP: CLEAR) Vercara: Vercara’s Web Application Firewall, UltraWAF, helps prevent common exploits of vulnerabilities in web applications that could lead to insertion of malware. Signatures for new vulnerabilities are constantly updated along with granular input validation controls and traffic filtering measures for flexibility. UltraWAF includes a number of tools for managing both benign and malicious bots including bot signatures and device fingerprinting. UltraWAF can also prevent some layer 7 DDoS attacks.
Source: https://cybersecuritynews.com/patch-for-xss-vulnerability-in-file-rendering/
New JavaScript Attack Hijacking Government and University Websites
(TLP: CLEAR) A sophisticated
(TLP: CLEAR) Comments: The Document
(TLP: CLEAR) Recommended best practices/regulations: OWASP Web Application Firewall: “A ‘web application firewall (WAF)’ is an application firewall for HTTP applications. It applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as Cross-site Scripting (XSS) and SQL Injection. “While proxies generally protect clients, WAFs protect servers. A WAF is deployed to protect a specific web application or set of web applications. A WAF can be considered a reverse proxy. “WAFs may come in the form of an appliance, server plugin, or filter, and may be customized to an application. The effort to perform this customization can be significant and needs to be maintained as the application is modified.”
(TLP: CLEAR) Vercara: Vercara’s Web Application Firewall, UltraWAF, protects your applications from data breaches, defacements, malicious bots, and other web application-layer attacks. By protecting your applications no matter where they are hosted, UltraWAF simplifies your operations through consistently configured rules with no provider restrictions or hardware requirements.
Source: https://cybersecuritynews.com/javascript-attacks-targeting/
DeepSeek Halts New Signups Amid “large-scale” Cyberattack
(TLP: CLEAR) Chinese AI
(TLP: CLEAR) Comments: The cyberattack
(TLP: CLEAR) Recommended best practices/regulations: NIST Special Publication 800-41 Revision 1, “Guidelines on Firewalls and Firewall Policy”: “Application firewalls can enable the identification of unexpected sequences of commands, such as issuing the same command repeatedly or issuing a command that was not preceded by another command on which it is dependent. These suspicious commands often originate from buffer overflow attacks, DoS attacks, malware, and other forms of attack carried out within application protocols such as HTTP. Another common feature is input validation for individual commands, such as minimum and maximum lengths for arguments. For example, a username argument with a length of 1000 characters is suspicious—even more so if it contains binary data.”
Request for Comments (RFC) 2827/Best Common Practice (BC) 38: “Ingress traffic filtering at the periphery of Internet connected networks will reduce the effectiveness of source address spoofing denial of service attacks. Network service providers and administrators have already begun implementing this type of filtering on periphery routers, and it is recommended that all service providers do so as soon as possible. In addition to aiding the Internet community as a whole to defeat this attack method, it can also assist service providers in locating the source of the attack if service providers can categorically demonstrate that their network already has ingress filtering in place on customer links.”
(TLP: CLEAR) Vercara: Vercara’s Web Application Firewall, UltraWAF, equips your company with adaptable security features to counteract the most significant network and application-layer threats, including SQL injection, XSS, and DDoS attacks. Its always-on security posture, combined with cloud-based scalability, ensures comprehensive protection against the OWASP top 10, advanced bot management, and vulnerability scanning, allowing you to effectively shield your critical and customer-facing applications from emerging threats.
Vercara UltraDDoS Protect provides flexible, automated, and always-on protection across 15 Points of Presence (PoPs) and >15Tbps of DDoS mitigation capacity to enable customer availability and performance under even the largest and most complex DDoS attacks (layer 3 through layer 7). An automated intelligence feed that is constantly updating mitigation devices allows protection against emerging attack vectors and common attack sources.
Google Researchers Breakdowns the Malware Obfuscator Scatterbrain
(TLP: CLEAR) Google’s Threat Intelligence
(TLP: CLEAR) Comments: APT41 is a
(TLP: CLEAR) Recommended best practices/regulations: CI-DSS V4.0 Section 5.2: “Malicious software (malware) is prevented or detected and addressed.
An anti-malware solution(s) is deployed on all system components, except for those system components identified in periodic evaluations per Requirement 5.2.3 that concludes the system components are not at risk from malware. The deployed anti-malware solution(s):
- Detects all known types of malware.
- Removes, blocks, or contains all known types of malware.
Any system components that are not at risk for malware are evaluated periodically to include the following:
- A documented list of all system components not at risk for malware.
- Identification and evaluation of evolving malware threats for those system components.
- Confirmation whether such system components continue to not require anti-malware protection.
The frequency of periodic evaluations of system components identified as not at risk for malware is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
Section 5.2 lays out requirements for malware detection and blocking across all devices in the Cardholder Data Environment. Every device inside of the CDE should have malware protection that is updated, monitored, and actions taken when an infection is detected.
(TLP: CLEAR) Vercara: Vercara’s Protective DNS solution, UltraDDR (DNS Detection and Response), uses a multi-petabyte data lake filled with DNS query history and indicators of compromise from multiple Cyber Threat Intelligence (CTI) data feeds to correlate an incoming DNS query in real-time with previously observed malicious activity. This ensures that users and devices only go to safe, policy-compliant Internet locations.
Source: https://cybersecuritynews.com/google-researchers-breakdowns-the-scatterbrain/
Hellcat Ransomware Attacking Organization in Raas Model With Affiliates
(TLP: CLEAR) A new ransomware group, Hellcat, has emerged as a significant cybersecurity threat, leveraging a Ransomware-as-a-Service (RaaS) model to target critical sectors, including government, education, and energy. First identified in mid-2024, Hellcat provides ransomware tools and infrastructure to affiliates in exchange for a percentage of ransom profits, enabling rapid scaling and high-value entity targeting. The group employs double-extortion tactics, first exfiltrating sensitive data before encrypting systems and threatening to leak stolen information unless a ransom is paid. Researchers from CATO Networks discovered that Hellcat uses the Windows Cryptographic API for encryption, ensuring that file contents are encrypted without altering file extensions or metadata. This technique minimizes system disruption while maximizing leverage over victims. The group is known for exploiting vulnerabilities in enterprise tools for initial access, as seen in November 2024, when Hellcat infiltrated Schneider Electric’s Atlassian Jira system via a zero-day vulnerability, stealing over 40GB of sensitive data. The attackers demanded $125,000 in Monero cryptocurrency, mockingly referring to the ransom as “baguettes” due to Schneider Electric’s French origins. Analysis of Hellcat’s payloads suggests a strong connection to the RaaS group Morpheus, as both share similar ransom notes, encryption exclusions for critical system files, and dark web payment portals.
Hellcat has conducted several high-profile attacks, including:
- Schneider Electric: Exposed operational data and employee details; the company refused to pay the ransom.
- Tanzania’s College of Business Education: Leaked 500,000+ records containing student and staff personal data.
- U.S. University: Offered root access to university servers for $1,500 on dark web forums, risking exposure of student records.
- Iraq City Government: Advertised municipal server access for $300, indicating a willingness to disrupt public services.
To mitigate such threats, organizations should implement Zero Trust Network Access (ZTNA) frameworks to restrict unauthorized access, regularly patch enterprise tool vulnerabilities (such as Jira), and deploy advanced threat detection systems capable of identifying ransomware behaviors. Hellcat’s reliance on the RaaS model has made sophisticated attacks widely accessible to affiliates, creating significant challenges for cybersecurity professionals worldwide.
(TLP: CLEAR) Comments: The rise of Hellcat as a Ransomware-as-a-Service (RaaS) operation highlights the increasing commercialization of cybercrime, enabling even low-skilled affiliates to execute high-impact ransomware attacks. By employing double-extortion tactics, where data is exfiltrated before encryption, Hellcat ensures that victims remain vulnerable to public data leaks even if they refuse to pay the ransom. The zero-day exploitation of Atlassian Jira at Schneider Electric demonstrates the group’s ability to target enterprise tools for initial access, reinforcing the need for continuous vulnerability management and Zero Trust security frameworks. Additionally, Hellcat’s use of the Windows Cryptographic API allows it to encrypt files without altering extensions or metadata, evading traditional ransomware detection mechanisms. Its willingness to sell unauthorized access to government and educational servers rather than just demanding ransom payments signals a shift towards long-term monetization of compromised systems, further complicating mitigation efforts for cybersecurity professionals worldwide.
(TLP: CLEAR) Recommended best practices/regulations: NIST Cybersecurity Framework (CSF) DE.CM-01: “Networks and network services are monitored to find potentially adverse events”. One of the ways to detect phishing, malware droppers, and command and control (C2) is at the network level. Intrusion Detection Systems (IDS), Intrusion Detection Systems (IPS), and next-generation firewalls can be used with a protective DNS solution to detect these malicious activities as they traverse the network, even if the initial infection occurs via physical media or on another network such as a hotel or airport.
(TLP: CLEAR) Vercara: Vercara’s Protective DNS solution, UltraDDR (DNS Detection and Response), functions as a complement to anti-virus and Endpoint Detection and Response (EDR) agents to reduce the total amount of malware infections.
Source: https://cybersecuritynews.com/hellcat-ransomware-attacking-organization/
AI Surge Drives Record 1205% Increase in API Vulnerabilities
(TLP: CLEAR) API vulnerabilities linked to AI deployment have increased by 1205% in the past year, according to the 2025 API ThreatStats Report by Wallarm. The report highlights that 99% of AI-related security issues stem from API flaws, with 57% of AI-powered APIs externally accessible and 89% lacking secure authentication. Only 11% of organizations have implemented robust security measures to protect AI-integrated APIs.
In 2024, Wallarm tracked 439 AI-related CVEs, many caused by injection flaws, misconfigurations, and a newly identified threat—Memory Corruption and Overflow vulnerabilities, linked to high-performance binary APIs used in AI systems.
For the first time, over 50% of all CISA-exploited vulnerabilities were API-related, up from 20% in 2023. Among these, 33.5% targeted modern RESTful and GraphQL APIs, while 18.9% affected legacy APIs such as AJAX-based systems. Real-world breaches highlight the risks, including the Dell API breach (49M records exposed), Twilio’s Authy exploit (33.4M phone numbers compromised), and Ascension Health’s API breach (5.6M patient records affected).
Key Findings:
- AI deployment drives API vulnerabilities – 53% of enterprises engaged in AI projects.
- Authentication flaws persist – 89% of AI-powered APIs lack secure authentication.
- Both modern and legacy APIs are at risk – 33% of CISA KEV vulnerabilities involve modern APIs.
- Memory corruption vulnerabilities emerge – AI’s reliance on high-performance computing introduces new risks.
- API breaches tripled in 2024 – Incidents rose from a few per quarter to multiple per month.
As APIs become the backbone of AI integration, Wallarm urges organizations to adopt real-time security controls to mitigate risks, emphasizing the critical need for API security in protecting operations, data, and reputation.
(TLP: CLEAR) Comments: The 1,205% increase in API vulnerabilities highlights a growing security crisis, as organizations increasingly rely on APIs for critical data exchanges and system integrations. The lack of authentication in 89% of externally exposed APIs leaves them highly vulnerable to unauthorized access, data breaches, and system takeovers. Injection flaws, misconfigurations, and newly emerging memory corruption vulnerabilities further expand the attack surface, allowing threat actors to exploit APIs for remote code execution (RCE), privilege escalation, and data exfiltration. The CISA-exploited vulnerability data showing that over 50% of critical security flaws involve APIs demonstrates how both modern RESTful/GraphQL APIs and legacy AJAX-based APIs are prime targets for cybercriminals. Major breaches, such as those affecting Dell (49M records), Twilio (33.4M records), and Ascension Health (5.6M records), illustrate the severe real-world consequences of poor API security, leading to massive data leaks, identity fraud risks, and service disruptions. As API-related breaches have tripled, organizations must prioritize real-time API security controls, enforce strict authentication measures, and implement continuous monitoring to prevent exploitation. Without proactive security measures, API vulnerabilities will remain a primary entry point for large-scale cyberattacks, threatening sensitive data, business continuity, and regulatory compliance.
(TLP: CLEAR) Recommended best practices/regulations: OWASP API Top 10, API9:2023 “Improper Inventory Management”:
- Inventory all API hosts and document important aspects of each one of them, focusing on the API environment (e.g. production, staging, test, development), who should have network access to the host (e.g. public, internal, partners) and the API version.
- Inventory integrated services and document important aspects such as their role in the system, what data is exchanged (data flow), and their sensitivity.
- Document all aspects of your API such as authentication, errors, redirects, rate limiting, cross-origin resource sharing (CORS) policy, and endpoints, including their parameters, requests, and responses.
- Generate documentation automatically by adopting open standards. Include the documentation build in your CI/CD pipeline.
- Make API documentation available only to those authorized to use the API.
- Use external protection measures such as API security specific solutions for all exposed versions of your APIs, not just for the current production version.
- Avoid using production data with non-production API deployments. If this is unavoidable, these endpoints should get the same security treatment as the production ones.
- When newer versions of APIs include security improvements, perform a risk analysis to inform the mitigation actions required for the older versions. For example, whether it is possible to backport the improvements without breaking API compatibility or if you need to take the older version out quickly and force all clients to move to the latest version.
(TLP: CLEAR) Vercara: Vercara UltraAPI offers a comprehensive solution to the complex challenges security teams face in safeguarding API applications against cyber threats. It provides thorough discovery of the entire API landscape, including external and internal APIs, assesses API risk posture to highlight critical vulnerabilities needing remediation, and delivers real-time protection to prevent API attacks, ensuring data safety, preventing fraud, and avoiding business disruptions. This solution stands out by addressing every phase of the API security lifecycle, promoting best practices in security and governance to eliminate risks effectively.
Source: https://www.infosecurity-magazine.com/news/ai-surge-record-1205-increase-api/