An alleged sale of unpatched critical zero-day exploits targeting Floci, Gitea, libssh, and c-ares highlights a growing threat. While the zero-day claims on dark web forums are likely fraudulent, the weaponization of legitimate public research repositories poses an immediate risk to enterprise networks.
Unauthorized remote code execution in developer environments, source code management platforms, and perimeter servers represents a critical operational risk for modern enterprises. A threat actor posting on darkforums.ru claims to sell multiple unpatched critical zero-day exploits targeting Floci, Gitea, libssh, and c-ares, all allegedly sourced from a GitHub repository known as "Bikini/Exploitarium". While technical intelligence indicates that the zero-day label in this sale is likely an attempt to scam other underground buyers, the highly functional proof-of-concept codes contained in this repository present real, immediate exploits that automated scanning tools and malicious actors can easily weaponize against unpatched internet-facing assets.
Analysis of the legitimate repository reveals it is a consolidated archive of public proof-of-concept exploits and vulnerability research write-ups maintained by an offensive security researcher. While some exploits in the archive target resolved vulnerabilities, the high-profile release of critical exploits has led threat actors to weaponize or scam others using the repository name. Threat actors are likely utilizing the highly credible name to market fake exploit packages or are bundling recently resolved critical exploits as zero-days to deceive other threat actors and security teams. To defend against these opportunistic threats, organizations must maintain an active stance on security by utilizing Attack Surface Management to detect exposed resources before adversaries can execute payloads.
Free exposure check
Dark Web Scanner
check dark web mentions, compromised account indicators, malware log signals, public breach exposure, and recent underground market activity for your domain.
The danger of this dark web threat does not stem from genuine undisclosed zero-day exploits, but rather from the ease with which sophisticated public research can be integrated into automated exploit chains. This section details the key technical components mentioned in the threat actor's post, highlighting the true underlying risks of each asset.
The vulnerability resides in the transport read function within the library. The code fails to enforce an upper bound on the attacker-controlled packet length field before using it to calculate the heap allocation size for decrypted packets. This causes a 32-bit integer wraparound, resulting in a tiny, undersized buffer allocation. When subsequent code copies packet contents based on the original large length value, it writes beyond the allocated buffer, corrupting the heap and allowing remote code execution. This is a client-side pre-authentication RCE which makes any outward connection from a vulnerable application to a compromised or malicious server highly dangerous.
The repository contains proof of concept files targeting Gitea's Act Runner configuration, specifically demonstrating container option manipulation to achieve host escapes. Additionally, Gitea environments face critical authentication bypass risks, particularly when misconfigured trusted proxies allow arbitrary admin impersonation via a single HTTP header. Attackers can leverage these misconfigurations to gain full administrative access to repositories, allowing them to inject malicious code directly into production pipelines.
While some public discussions point to denial of service bugs in c-ares, the active enterprise risk often involves how attackers abuse the library's utility tools. Specifically, threat actors routinely target components like the c-ares executable via DLL side-loading techniques to bypass host security controls. By placing a malicious payload inside a trusted directory alongside the legitimate utility, attackers can execute advanced backdoors and info-stealers under the guise of legitimate system activity.
Floci is an open-source local AWS service emulator built with Quarkus Native, often used as an alternative to LocalStack in development environments. In offensive security labs, Floci is targeted via Server-Side Request Forgery (SSRF) to exploit internal queue systems, leading to container escapes. Claims of unpatched Floci zero-days are generally inflated, as the root vulnerabilities stem from deploying local emulators with excessive privileges, such as exposing the host docker socket to the container.
Vulnerable client connects to malicious SSH server
Standard key exchange initiated without credentials
Server sends excessive packet_length (0xffffffff)
Client arithmetic wraps, allocating undersized heap buffer
Client copies packet, writing beyond allocated bounds
Corrupted callback pointers hijack execution flow
If your team may be exposed to a similar threat, FemtoSec can help validate blast radius, prioritize remediation, and connect the issue to a practical security program.
A threat actor is auctioning a zero-day exploit targeting an undisclosed WordPress plugin with over 10,000 active installations. The vulnerability allows low-privileged users with the create_users capability to escalate to Administrator, leading to full site takeover. Discover detection and containment strategies.
June 11, 2026
A threat actor claims to possess advanced zero-day exploits and attack techniques targeting network infrastructure and browsers. We analyze the implications for enterprises.
June 19, 2026
A reported zero-day exploit targeting Local Privilege Escalation (LPE) in Windows presents a significant risk to enterprise security, potentially allowing attackers to elevate permissions and compromise system integrity.
Security teams should take immediate action to isolate developmental tools and secure core dependencies. This includes restricting external network access for developer environments, enforcing strict egress filtering, and blocking access to known exploit hubs at the perimeter.
Furthermore, configuration audits are essential. Gitea trusted proxies should never be set to accept wildcard entries, and any containerized testing environment must run without mounting the host root docker socket. Upgrading library dependencies to verified, secure versions is the only definitive way to resolve underlying heap execution vulnerabilities and eliminate the risks highlighted by these public exploit packages.
To help security engineers visualize how the critical client-side vulnerability works in practice, we outline the primary execution sequence:
Initial Connection: A client application linking a vulnerable version of the library (such as automated backup agents, custom command line tools, or embedded firmware) initiates an outbound connection to a malicious SSH server controlled by the attacker.
Pre-Auth Handshake: The client and malicious server initiate the standard key exchange handshake. No user authentication or credentials are required to trigger this phase.
Payload Delivery: The malicious server sends an encrypted transport-layer packet containing a crafted, excessively large packet length field.
Integer Wraparound: The client-side library computes the allocation size using the attacker-controlled length in an arithmetic expression. The calculation wraps around, resulting in a tiny heap buffer allocation.
Memory Corruption: The library attempts to read the payload, trusting the original large length value for its decryption copy bounds. It writes far beyond the allocated buffer, corrupting adjacent heap chunks and overwriting function pointers.
Execution Impact: When the application subsequently executes a corrupted callback pointer, the execution flow is hijacked, running arbitrary payload code on the client machine with the permissions of the parent application.
Identifying exploitation attempts or the presence of weaponized components from the repository requires a multi-layered detection approach. Enterprises should deploy specific host and network checks to discover vulnerable or active exploits.
To check for potential developer system exploitation or local repository activity, teams can deploy a YARA rule designed to target the arithmetic verification scripts associated with the public exploit package:
rule Detect_Exploitarium_libssh2_Probe {
meta:
description = "Detects the arithmetic verifier from the exploitarium repository"
author = "FemtoSec Threat Intelligence"
date = "2026-06-26"
strings:
$arithmetic_1 = "cve_2026_55200_probe" ascii wide
$packet_len_check = "--packet-length" ascii wide
$exploit_ref = "exploitarium/libssh2-cve-2026-55200-poc" ascii wide
condition:
any of them
}In addition to YARA rules, security teams should implement process creation monitoring for utility programs like the c-ares executable, flagging any instance where it spawns child shells or runs from temporary directories. Organizations should also regularly engage in proactive Vulnerability Assessments to detect and remediate unpatched dependencies across all production and staging environments.