Customer portal
Articles Tagged with

SOS Intelligence

"SOS
CVE Top 10

The SOS Intelligence CVE Chatter Weekly Top Ten – 17 August 2026

 

This weekly blog post is from via our unique intelligence collection pipelines. We are your eyes and ears online, including the Dark Web.

There are thousands of vulnerability discussions each week. SOS Intelligence gathers a list of the most discussed Common Vulnerabilities and Exposures (CVE) online for the previous week.

We make every effort to ensure the accuracy of the data presented. As this is an automated process some errors may creep in.

If you are feeling generous please do make us aware of anything you spot, feel free to follow us on Twitter @sosintel and DM us. Thank you!

 


 

1.  CVE-2024-51479

Axios is a promise based HTTP client for the browser and Node.js. Prior to 1.15.0 and 0.31.0, Axios does not correctly handle hostname normalization when checking NO_PROXY rules. Requests to loopback addresses like localhost. (with a trailing dot) or [::1] (IPv6 literal) skip NO_PROXY matching and go through the configured proxy. This goes against what developers expect and lets attackers force requests through a proxy, even if NO_PROXY is set up to protect loopback or internal services. This issue leads to the possibility of proxy bypass and SSRF vulnerabilities allowing attackers to reach sensitive loopback or internal services despite the configured protections. This vulnerability is fixed in 1.15.0 and 0.31.0.

https://nvd.nist.gov/vuln/detail/CVE-2024-51479

 


 

2. CVE-2025-62718

Axios is a promise based HTTP client for the browser and Node.js. Prior to 1.15.0 and 0.31.0, Axios does not correctly handle hostname normalization when checking NO_PROXY rules. Requests to loopback addresses like localhost. (with a trailing dot) or [::1] (IPv6 literal) skip NO_PROXY matching and go through the configured proxy. This goes against what developers expect and lets attackers force requests through a proxy, even if NO_PROXY is set up to protect loopback or internal services. This issue leads to the possibility of proxy bypass and SSRF vulnerabilities allowing attackers to reach sensitive loopback or internal services despite the configured protections. This vulnerability is fixed in 1.15.0 and 0.31.0.

https://nvd.nist.gov/vuln/detail/CVE-2025-62718

 


 

3. CVE-2026-32315

motionEye (mEye) is an online interface for motion software, a video surveillance program with motion detection. Versions prior to 0.44.0 create the configuration file /etc/motioneye/motion.conf with 644 permissions (-rw-r–r–), making it readable by any local user on the system. This file contains sensitive data including the admin password hash, which can be leveraged by other vulnerabilities to escalate privileges. Additionally, per-camera configuration files (camera-*.conf) are also created with the same 644 permissions, potentially exposing camera-specific credentials and settings. The exposed SHA1 admin password hash can be cracked offline to recover the plaintext password, used directly to forge authenticated admin API requests via the signature authentication weakness (GHSA-45h7-499j-7ww3), and chained with the OS command injection flaw (CVE-2025-60787) to escalate a local unprivileged user to the Motion daemon user (often root), enabling full system compromise. This issue has been fixed in version 0.44.0.

https://nvd.nist.gov/vuln/detail/CVE-2026-32315

 


 

4. CVE-2019-20790

OpenDMARC through 1.3.2 and 1.4.x allows attacks that inject authentication results to provide false information about the domain that originated an e-mail message. This is caused by incorrect parsing and interpretation of SPF/DKIM authentication results, as demonstrated by the example.net(.example.com substring.

https://nvd.nist.gov/vuln/detail/CVE-2019-20790

 


 

5. CVE-2020-12272

OpenDMARC through 1.3.2 and 1.4.x allows attacks that inject authentication results to provide false information about the domain that originated an e-mail message. This is caused by incorrect parsing and interpretation of SPF/DKIM authentication results, as demonstrated by the example.net(.example.com substring.

https://nvd.nist.gov/vuln/detail/CVE-2020-12272

 


 

6. CVE-2026-60137

WordPress 6.8.x before 6.8.6, 6.9.x before 6.9.5, and 7.0.x before 7.0.2 does not properly sanitise the author__not_in parameter of WP_Query, which could allow SQL Injection when a plugin or theme passes untrusted input to the parameter.

https://nvd.nist.gov/vuln/detail/CVE-2026-60137

 


 

7. CVE-2026-63030

WordPress 6.8.x before 6.8.6, 6.9.x before 6.9.5, and 7.0.x before 7.0.2 does not properly sanitise the author__not_in parameter of WP_Query, which could allow SQL Injection when a plugin or theme passes untrusted input to the parameter.

https://nvd.nist.gov/vuln/detail/CVE-2026-63030

 


 

8. CVE-2019-11090

STMicroelectronics ST33TPHF2ESPI TPM devices before 2019-09-12 allow attackers to extract the ECDSA private key via a side-channel timing attack because ECDSA scalar multiplication is mishandled, aka TPM-FAIL.

https://nvd.nist.gov/vuln/detail/CVE-2019-11090

 


 

9. CVE-2019-16863

STMicroelectronics ST33TPHF2ESPI TPM devices before 2019-09-12 allow attackers to extract the ECDSA private key via a side-channel timing attack because ECDSA scalar multiplication is mishandled, aka TPM-FAIL.

https://nvd.nist.gov/vuln/detail/CVE-2019-16863

 


 

10. CVE-2023-1017

STMicroelectronics ST33TPHF2ESPI TPM devices before 2019-09-12 allow attackers to extract the ECDSA private key via a side-channel timing attack because ECDSA scalar multiplication is mishandled, aka TPM-FAIL.

https://nvd.nist.gov/vuln/detail/CVE-2023-1017

 


"Stealer
Investigation, The Dark Web

Stealer Logs: Understanding the Underground’s Most Dangerous Data Source

Introduction

Stealer logs represent the most dangerous commoditised threat to corporate security today. Unlike traditional data breaches that target specific organisations, infostealers cast a wide net across millions of users and machines, capturing everything from browser credentials to session tokens to cryptocurrency wallets in a single automated sweep.

So why are stealer logs such a critical concern right now? Because they are the common precursor to account takeover, ransomware deployment, and initial access brokerage. If your users’ credentials are in a stealer log marketplace, you do not have an identity problem; you have a breach waiting to happen.

This report examines what stealer logs are, how they are distributed and monetised, what data they contain, and how organisations can detect and defend against them. The scale is staggering: in the first half of 2025 alone, over 180,000 stealer logs were offered for sale on underground marketplaces. RedLine accounts for 44% of all logs collected. Vidar stole 65 million passwords in just six months.

If your domain appears in a stealer log, you are no longer operating under the assumption of credential compromise; you are operating under the certainty of it. The only question is whether the threat actor has already acted on that access.

How Infostealers Work

The Malware Itself

An infostealer is malware designed with a single purpose: to extract sensitive data from an infected machine and exfiltrate it to an attacker-controlled server. It runs silently, often with minimal resource consumption, which is why users and security teams can miss it for weeks or months.

So what data do they target? Browser autofill data, stored passwords, session cookies, saved payment card details, cryptocurrency wallet seed phrases and private keys, email account credentials, browser extensions, browsing history, installed software inventory, system information, and USB device history. The malware is indiscriminate; it grabs everything that might have value.

The sophistication varies. Basic infostealers are crude tools designed to grab whatever they can reach. Advanced infostealers include anti-analysis features, anti-virtualisation checks, geofencing to avoid high-risk jurisdictions, and code obfuscation to bypass signature-based detection.

Major Infostealer Families

RedLine is the dominant family by volume. First observed in 2020, RedLine has evolved into a modular stealer with customisable features, support for multiple languages and operating systems, and active development. It accounts for 44% of all stealer logs captured by intelligence vendors. RedLine spreads primarily through cracked software, malicious advertising networks, and watering hole attacks targeting development forums.

Raccoon was one of the earliest widespread infostealers and became infamous for its ease of use and low barrier to entry. Variant developers could build custom builds for under $100. Although law enforcement operations disrupted Raccoon’s primary infrastructure in 2023 (following the October 2022 arrest of developer Mark Sokolovsky), variants continue to circulate. Raccoon logs are heavily discounted on marketplaces because the payloads are dated and signatures are well-known.

Vidar is one of the most aggressive and feature-rich infostealers in circulation. It records keystrokes, captures screenshots, exfiltrates browser data, and includes anti-reverse-engineering protections. Vidar was responsible for stealing 65 million passwords in a documented six-month period from 2024 to 2025. It spreads through malvertising, cracked software, and compromised download mirrors.

Lumma emerged in 2022 and gained traction rapidly because of its effective distribution mechanism and low detection rates. Lumma’s primary distribution vector is Trojanised legitimate software (video converters, games, file managers) distributed through third-party sites. Lumma logs are actively traded on underground markets at premium prices because they tend to contain fresh, high-value data.

The Malware-as-a-Service Model

Most modern infostealers operate as a service, not a discrete product. Operators host the command and control infrastructure, provide a web panel for customers to manage infections and download logs, and take a percentage of the revenue when logs are resold.

The client (a threat actor, distributor, or criminal organisation) uses the service to build custom malware variants, deploy them through their chosen vectors, and collect the resulting logs. The service operator handles the backend; the client handles distribution and monetisation.

This model democratises malware development. You do not need to be a skilled reverse engineer or malware author; you just need access to a distribution channel and a payment method. Prices for malware-as-a-service access range from $40 per month for basic builds to $500 per month for fully customised, high-stealth variants with obfuscation and anti-analysis features.

The Stealer Log Supply Chain: From Infection to Marketplace

Step One: Distribution

The first stage of the supply chain is getting the malware onto the target machine. Distribution methods include cracked software (the single largest vector), malicious advertisements and browser redirects, compromised legitimate software mirrors, phishing emails with trojanised attachments, and watering hole attacks targeting developers and specific industries.

Cracked software remains the dominant distribution method because the economics are simple: users want free versions of expensive software, threat actors provide infected versions, and the malware runs with the privileges of the software installation. Commonly trojanised products include AutoCAD, Microsoft Office, Photoshop, Ableton Live, JetBrains IDEs, and antivirus software itself. Underground marketplaces such as zqi3evypxq7ok3gqnimwnlesf6v76ksrpgtgb6j7hh6ye752apzmceyd[.]onion advertise cracking tools and hacking guides alongside stealer logs.

Step Two: Execution and Exfiltration

Once executed, the infostealer begins its automated collection routine. It enumerates installed browsers, reads credential storage databases, decrypts stored passwords using the operating system’s credential storage APIs, extracts browser cookies (which often contain active session tokens for web services), and collects any data it has permissions to access.

So what happens to this data once collected? The malware packages it into an archive (typically JSON or CSV format), compresses it, and sends it back to the attacker’s command and control server. This happens in seconds to minutes, often without any user-visible activity. Encryption in transit is variable; some stealers use HTTPS, others use simple obfuscation.

Step Three: Log Curation and Testing

The logs arrive at the attacker’s server in raw form. Experienced threat actors filter and verify logs before offering them for sale. They test login credentials against target services to confirm validity, check whether emails are associated with high-value targets (executives, technical staff, security personnel), and flag logs that contain cryptocurrency wallet data or payment card information for premium pricing.

A high-quality stealer log contains verified working credentials, a mix of personal and corporate accounts, cryptocurrency wallet information, and identifiable metadata such as system username and company name extracted from the system registry. Low-quality logs are unverified, old (more than a week old), or contain duplicates.

Step Four: Marketplace and Distribution

Verified logs are uploaded to underground marketplaces. The three most significant distribution channels are the Russian Market (a Telegram-native marketplace with automated purchasing and delivery), Genesis Market (a long-standing marketplace specialising in session cookies and browser profile data, subject to FBI takedown in April 2023 as part of Operation Cookie Monster), and ad hoc Telegram channels run by individual threat actors or resellers.

Pricing follows a predictable pattern: individual consumer logs $1 to $5, logs containing cryptocurrency or payment card data $10 to $50, corporate or email logs $20 to $100, and bulk access to large log repositories $1,000 to $5,000, depending on scope and recency. Some marketplaces offer subscription models where buyers pay $200 to $500 per month for unlimited access to new logs.

Step Five: Exploitation

Once purchased, the logs are used for account takeover (directly accessing email, SaaS applications, or banking portals), credential stuffing attacks against non-customers, password spray attacks across corporate networks, identification of high-value targets for targeted phishing or social engineering, and sales to other threat actors, ransomware gangs, or initial access brokers.

The timeline from infection to exploitation can be remarkably short. Logs may be available for purchase within 24 to 72 hours of infection. Active threat actors monitor marketplaces continuously, purchasing logs for targets relevant to their operations immediately after they appear for sale.

What’s Inside a Stealer Log

A typical stealer log is a structured data archive containing the following categories of information.

Browser Credentials

Passwords are stored in Chrome, Firefox, Edge, Opera, and other Chromium-based browsers. These are extracted using the browser’s own decryption APIs and are usually in plaintext in the log. If your users are reusing passwords across multiple services (which most do), a single compromised password gives access to email, SaaS applications, banking portals, and corporate networks.

Session Cookies and Browser Data

Session cookies are particularly valuable because they often grant access to authenticated services without requiring the user to log in again. A stolen cookie for a user’s email account, for example, allows an attacker to reset the password for every service that user has signed up for. Logs also contain browser autofill data, saved addresses, phone numbers, and credit card information.

Cryptocurrency Wallet Data

If the infected machine has a cryptocurrency wallet installed (MetaMask, Trust Wallet, Ledger, Trezor drivers), the infostealer attempts to extract wallet seed phrases, private keys, and transaction history. A stolen seed phrase gives the attacker full control of any cryptocurrency stored in that wallet. Logs containing wallet data command a significant price premium, with cryptocurrency-focused marketplaces like tamazoncmlw2ohkbsmqxnotudejdd4befrasxuigzzjumqu3zba535yd[.]onion advertising cloned cards and financial fraud tools alongside wallet data.

System and User Information

The log includes the machine’s hostname, registered Windows username, installed software inventory, list of network interfaces and IP addresses, list of USB devices ever connected, system serial number, and BIOS information. This metadata helps threat actors profile the target (e.g. is this a developer machine, does it have security software installed) and tailor exploitation.

Email and Application Data

If Outlook, Thunderbird, or other email clients are installed, logs may contain saved email credentials and cached email headers. Application-specific data is also captured, including saved credentials in password managers (if they are not properly locked), FTP clients, SSH keys, browser extensions, and stored API credentials in development tools.

Indicator Format

Logs are typically structured as JSON or CSV files within a ZIP archive. A single log might be 5 to 200 megabytes, depending on the system’s history and installed software. Large batch log collections can reach gigabytes and are broken into smaller chunks for distribution.

Key Statistics: The Scale of the Threat

RedLine accounts for 44% of all stealer logs analysed by intelligence platforms. This concentration means that if you are looking for signs of compromise via stealer logs, you are primarily tracking RedLine activity. However, that also means a significant proportion of logs come from other families like Vidar, Lumma, and Raccoon variants.

Vidar stole 65 million unique passwords in a documented six-month period from October 2024 to March 2025. This single family, operating from a single set of infrastructure, compromised a staggering volume of user accounts across consumer and corporate domains.

Over 180,000 stealer logs were offered for sale on identified underground marketplaces in the first half of 2025. This is an average of 30,000 logs per month, or roughly 1,000 logs per day.

More than 50% of ransomware victims had their domains listed in stealer logs before the ransomware deployment. This indicates that initial compromise via stealer log access is a primary precursor to ransomware attacks. Threat actors purchase logs to establish initial access, conduct reconnaissance, and stage the ransomware payload.

Major Infostealer Families

Stealer Log Pricing by Type

Impact Statistics

The Marketplace Ecosystem

Russian Market (Telegram Native)

Russian Market operates exclusively within Telegram and is the largest active stealer log marketplace as of 2025. The platform uses automated bots that handle purchasing, payment, and log delivery. Buyers simply send a payment in cryptocurrency and receive a direct link to download the log within minutes.

Russian Market does not charge a commission on individual sales; revenue comes from premium marketplace memberships, advertising, and selective enforcement of seller verification. The platform lists 50,000 to 100,000 logs at any given time, with new inventory added continuously.

Genesis Market

Genesis Market is a longer-established marketplace that specialises in session cookies, browser profiles, and authenticated user sessions rather than raw passwords. It operates a traditional web interface (accessed via Tor) and enforces strict verification of sellers. Genesis Market was subject to a major FBI takedown operation in April 2023.

Genesis Market takes a 10 to 15% commission on each sale. Logs on Genesis command higher prices than equivalent logs on the Russian Market because the payload (authenticated sessions) is more directly useful for account takeover without password changes. The marketplace has hosted millions of stolen sessions.

Telegram Channels and Resellers

Smaller threat actors and resellers operate ad hoc Telegram channels, often promoting newly harvested logs from specific geographic regions or specific malware families. These channels operate with less formal infrastructure and offer discounts for bulk purchases. Forums like bfdxjkv5e2z3ilrifzbnvxxvhbzsj67akjpj3zc6smzr4vv6oz565gyd[.]onion host escrow services and enable peer-to-peer trading of stolen logs.

Prices on Telegram are often lower than those on centralised marketplaces because resellers are trying to move inventory quickly and avoid law enforcement attention. However, logs are also less verified and may contain duplicates or stale data.

Regional Variations

Pricing and availability vary significantly by geography. Logs from developed economies (USA, UK, Germany, Japan) command premium prices. Logs from developing economies are discounted. Logs are also segmented by corporate association; logs from email addresses on Fortune 500 domain whitelists are marked as such and priced accordingly.

Corporate Risk: How Stealer Logs Enable Attacks

Account Takeover

The most direct exploitation path is account takeover. An attacker purchases a log containing the email address and password of a corporate employee. They attempt to log into the employee’s email account. If multi-factor authentication is not enabled (and many users do not enable it outside of work contexts), login succeeds.

From the email, the attacker resets passwords for every service the employee has linked to that email account. This includes SaaS applications, cloud storage, password managers, and often the employee’s corporate VPN or SSO portal if they have reused the same password across services.

Initial Access Brokerage

Ransomware gangs and APT operators do not have time to run large-scale malware campaigns. Instead, they purchase access from initial access brokers. An initial access broker uses stealer logs to identify high-value targets (corporate email addresses, domain admin accounts, people working for specific industries), purchases logs for those individuals, and then sells the access to ransomware operators or nation states.

A single log containing credentials for a domain admin or security operations centre staff member can sell for $5,000 to $50,000 to a ransomware operator, because that access drastically shortcuts the reconnaissance and lateral movement phases of a ransomware campaign.

Reconnaissance and Lateral Movement

Even if the initial compromised account is a low-privilege user, logs contain system information, installed software, network configuration, and connected USB devices. This metadata gives threat actors a profile of the corporate environment before they even gain access. They know which security software is in use, which development frameworks are deployed, and which network devices are present.

Once inside, the attacker uses the compromised account to access email (containing sensitive business information, network topology diagrams, and access credentials in forwarded messages), network drives, and internal tools. This leads to lateral movement to higher-privileged accounts and eventually to domain admin compromise.

Credential Stuffing and Password Spray

An attacker with a database of 1,000 stolen passwords can conduct password spray attacks against your corporate email system or Active Directory, trying the same password across all known email addresses in your organisation. The attack succeeds if employees have reused credentials or used predictable variations.

This is a silent attack that happens outside of your firewall and VPN, so your network monitoring tools do not detect it. The first sign may be unexpected password reset emails or successful logins from impossible locations.

Supply Chain Compromise

If your organisation relies on third-party software vendors or contractors, and those vendors’ employees are in the stealer logs, an attacker can compromise the vendor and use their access to gain indirect access to your systems. This is a far easier attack vector than breaching you directly.

How SOS Intelligence Monitors Stealer Logs

Our breach alert system continuously monitors underground marketplaces, forums, Telegram channels, and data dump collections for stealer logs and other sources of compromised data. We extract indicators of compromise from each log and match them against your organisational domains.

So how does detection work? We parse log contents for email addresses, domain names, usernames, system names, and other identifying information. We match these against your organisation’s known domain list. When we find a hit, we generate an alert with details: which user was compromised, which malware family was responsible (if known), what data was exposed, when the log appeared for sale, and what price it commanded on the marketplace.

We also track trends. We monitor which malware families are producing the most volume, which geographic regions are being targeted, and which industries are disproportionately represented in current stealer logs. This gives you visibility into both specific risks to your organisation and the broader threat landscape.

Our enrichment process adds context. We cross-reference the compromised email addresses with LinkedIn, WHOIS records, and internal threat intelligence to identify whether the compromised user holds a sensitive position (executive, developer, security staff). We flag logs that contain multiple compromised employees from the same organisation as indicators of targeted activity rather than random harvesting.

Defensive Recommendations

Detection and Monitoring

First: subscribe to breach alert services that monitor stealer log marketplaces and dark web collections. The earlier you know that your users are in stealer logs, the faster you can reset compromised credentials and audit for account access.

Second: implement continuous exposure monitoring. Track your organisational domains on dark web forums, marketplaces, pastebins, and leaked database collections. Many of these sources post publicly (just on obscure infrastructure); you do not need access to Telegram to find them.

Incident Response

If you discover that your domain is present in a stealer log, treat it as a credential compromise incident. Reset the password for the compromised user immediately. Force re-authentication on all active sessions (log them out everywhere). Enable multi-factor authentication if not already in use. Audit email forwarding rules, application integrations, and connected devices for signs of access.

Check whether the compromised user holds a sensitive role. If they do, expand your investigation: query your identity provider and email system for impossible logins, password changes, or unusual activity; check cloud storage for data exfiltration; and interview the user about recent phishing attempts or unusual system behaviour.

Credential Hygiene

Enforce strong, unique passwords for all systems, especially email and identity providers. Implement passwordless authentication where possible (FIDO2 hardware keys, Windows Hello). Where passwords are necessary, use a password manager with strong master passwords.

Multi-factor authentication is not optional; it is mandatory. If an attacker has your password (because it is in a stealer log), multi-factor authentication is the only thing that stops account takeover. Prioritise MFA for email and administrative accounts. Do not rely on SMS; use TOTP or hardware keys.

Threat Actor Knowledge

Understand which threat actors are currently targeting your industry. If you operate in critical infrastructure or financial services, you are targeted by state-sponsored actors and organised crime groups, not opportunistic cybercriminals. If you operate in technology or biotech, intellectual property theft is a primary motivation.

Review the malware families affecting your sector. If your users are appearing in Vidar or Lumma logs more frequently than average, your distribution channels may be compromised. If you see your domain in logs associated with a specific ransomware gang, you have a higher probability of imminent encryption activity.

Third-Party Risk

Audit your third-party vendors and contractors for Stealer log exposure. If a critical vendor has employees in breach, consider the implications for your access. Do they reuse passwords, or are their systems segmented? Do they have elevated privileges in your environment?

Implement zero-trust principles for vendor access. Do not assume that a contractor’s machine is clean; segment their access, require multi-factor authentication, and monitor their activity as you would a hostile external party.

Appendix: DARKSEARCH Observed Indicators

The following table documents confirmed indicators from dark web marketplaces and forums monitored via SOS Intelligence’s DARKSEARCH API. All onion addresses are defanged for security and compliance purposes. These indicators are provided for threat intelligence and detection purposes only.

External References

The analysis in this report draws on publicly available threat intelligence, academic research, and law enforcement activity reports. Key sources include:

Conclusion

Stealer logs are not a future threat; they are a present reality. The scale of harvesting, the sophistication of the malware, and the availability of stolen data on open marketplaces mean that credential compromise is no longer exceptional. It is expected.

Your organisation’s security posture must start with the assumption that your users’ credentials are compromised. That means: strong, unique passwords, multi-factor authentication, continuous monitoring of dark web sources, rapid response to breach alerts, and zero-trust policies for sensitive access.

The defenders who will prevail are those who detect compromise early and respond immediately. Every hour between when a stealer log appears on a marketplace and when you reset the compromised credentials is an hour the attacker can exploit that access.

If you do not have visibility into dark web stealer log marketplaces today, you do not have a complete picture of your organisation’s actual risk. Close that gap now.

Danger photo by Edwin Hooper on Unsplash

Malware photo by Ed Hardie on Unsplash

Browser photo by BoliviaInteligente on Unsplash

No trespassing photo by Joseph Corl on Unsplash

"SOS
CVE Top 10

The SOS Intelligence CVE Chatter Weekly Top Ten – 13 July 2026

 

This weekly blog post is from via our unique intelligence collection pipelines. We are your eyes and ears online, including the Dark Web.

There are thousands of vulnerability discussions each week. SOS Intelligence gathers a list of the most discussed Common Vulnerabilities and Exposures (CVE) online for the previous week.

We make every effort to ensure the accuracy of the data presented. As this is an automated process some errors may creep in.

If you are feeling generous please do make us aware of anything you spot, feel free to follow us on Twitter @sosintel and DM us. Thank you!

 


 

1.  CVE-2020-1938

A path traversal vulnerability affecting the Windows version of WinRAR allows the attackers to execute arbitrary code by crafting malicious archive files. This vulnerability was exploited in the wild and was discovered by Anton Cherepanov, Peter Košinár, and Peter Strýček
from ESET.

https://nvd.nist.gov/vuln/detail/CVE-2020-1938

 


 

2. CVE-2022-21227

A path traversal vulnerability affecting the Windows version of WinRAR allows the attackers to execute arbitrary code by crafting malicious archive files. This vulnerability was exploited in the wild and was discovered by Anton Cherepanov, Peter Košinár, and Peter Strýček
from ESET.

https://nvd.nist.gov/vuln/detail/CVE-2022-21227

 


 

3. CVE-2024-38063

A path traversal vulnerability affecting the Windows version of WinRAR allows the attackers to execute arbitrary code by crafting malicious archive files. This vulnerability was exploited in the wild and was discovered by Anton Cherepanov, Peter Košinár, and Peter Strýček
from ESET.

https://nvd.nist.gov/vuln/detail/CVE-2024-38063

 


 

4. CVE-2024-49113

A path traversal vulnerability affecting the Windows version of WinRAR allows the attackers to execute arbitrary code by crafting malicious archive files. This vulnerability was exploited in the wild and was discovered by Anton Cherepanov, Peter Košinár, and Peter Strýček
from ESET.

https://nvd.nist.gov/vuln/detail/CVE-2024-49113

 


 

5. CVE-2025-0368

A path traversal vulnerability affecting the Windows version of WinRAR allows the attackers to execute arbitrary code by crafting malicious archive files. This vulnerability was exploited in the wild and was discovered by Anton Cherepanov, Peter Košinár, and Peter Strýček
from ESET.

https://nvd.nist.gov/vuln/detail/CVE-2025-0368

 


 

6. CVE-2025-14847

A path traversal vulnerability affecting the Windows version of WinRAR allows the attackers to execute arbitrary code by crafting malicious archive files. This vulnerability was exploited in the wild and was discovered by Anton Cherepanov, Peter Košinár, and Peter Strýček
from ESET.

https://nvd.nist.gov/vuln/detail/CVE-2025-14847

 


 

7. CVE-2025-24118

A path traversal vulnerability affecting the Windows version of WinRAR allows the attackers to execute arbitrary code by crafting malicious archive files. This vulnerability was exploited in the wild and was discovered by Anton Cherepanov, Peter Košinár, and Peter Strýček
from ESET.

https://nvd.nist.gov/vuln/detail/CVE-2025-24118

 


 

8. CVE-2025-50708

A path traversal vulnerability affecting the Windows version of WinRAR allows the attackers to execute arbitrary code by crafting malicious archive files. This vulnerability was exploited in the wild and was discovered by Anton Cherepanov, Peter Košinár, and Peter Strýček
from ESET.

https://nvd.nist.gov/vuln/detail/CVE-2025-50708

 


 

9. CVE-2025-54100

A path traversal vulnerability affecting the Windows version of WinRAR allows the attackers to execute arbitrary code by crafting malicious archive files. This vulnerability was exploited in the wild and was discovered by Anton Cherepanov, Peter Košinár, and Peter Strýček
from ESET.

https://nvd.nist.gov/vuln/detail/CVE-2025-54100

 


 

10. CVE-2025-58434

A path traversal vulnerability affecting the Windows version of WinRAR allows the attackers to execute arbitrary code by crafting malicious archive files. This vulnerability was exploited in the wild and was discovered by Anton Cherepanov, Peter Košinár, and Peter Strýček
from ESET.

https://nvd.nist.gov/vuln/detail/CVE-2025-58434

 


"SOS
CVE Top 10

The SOS Intelligence CVE Chatter Weekly Top Ten – 06 July 2026

 

This weekly blog post is from via our unique intelligence collection pipelines. We are your eyes and ears online, including the Dark Web.

There are thousands of vulnerability discussions each week. SOS Intelligence gathers a list of the most discussed Common Vulnerabilities and Exposures (CVE) online for the previous week.

We make every effort to ensure the accuracy of the data presented. As this is an automated process some errors may creep in.

If you are feeling generous please do make us aware of anything you spot, feel free to follow us on Twitter @sosintel and DM us. Thank you!

 


 

1.  CVE-2025-54100

telnetd in GNU inetutils through 2.7 allows an out-of-bounds write in the LINEMODE SLC (Set Local Characters) suboption handler because add_slc does not check whether the buffer is full.

https://nvd.nist.gov/vuln/detail/CVE-2025-54100

 


 

2. CVE-2020-1938

telnetd in GNU inetutils through 2.7 allows an out-of-bounds write in the LINEMODE SLC (Set Local Characters) suboption handler because add_slc does not check whether the buffer is full.

https://nvd.nist.gov/vuln/detail/CVE-2020-1938

 


 

3. CVE-2025-50708

telnetd in GNU inetutils through 2.7 allows an out-of-bounds write in the LINEMODE SLC (Set Local Characters) suboption handler because add_slc does not check whether the buffer is full.

https://nvd.nist.gov/vuln/detail/CVE-2025-50708

 


 

4. CVE-2022-21227

telnetd in GNU inetutils through 2.7 allows an out-of-bounds write in the LINEMODE SLC (Set Local Characters) suboption handler because add_slc does not check whether the buffer is full.

https://nvd.nist.gov/vuln/detail/CVE-2022-21227

 


 

5. CVE-2024-38063

telnetd in GNU inetutils through 2.7 allows an out-of-bounds write in the LINEMODE SLC (Set Local Characters) suboption handler because add_slc does not check whether the buffer is full.

https://nvd.nist.gov/vuln/detail/CVE-2024-38063

 


 

6. CVE-2024-49113

telnetd in GNU inetutils through 2.7 allows an out-of-bounds write in the LINEMODE SLC (Set Local Characters) suboption handler because add_slc does not check whether the buffer is full.

https://nvd.nist.gov/vuln/detail/CVE-2024-49113

 


 

7. CVE-2025-0368

telnetd in GNU inetutils through 2.7 allows an out-of-bounds write in the LINEMODE SLC (Set Local Characters) suboption handler because add_slc does not check whether the buffer is full.

https://nvd.nist.gov/vuln/detail/CVE-2025-0368

 


 

8. CVE-2025-14847

telnetd in GNU inetutils through 2.7 allows an out-of-bounds write in the LINEMODE SLC (Set Local Characters) suboption handler because add_slc does not check whether the buffer is full.

https://nvd.nist.gov/vuln/detail/CVE-2025-14847

 


 

9. CVE-2025-24118

telnetd in GNU inetutils through 2.7 allows an out-of-bounds write in the LINEMODE SLC (Set Local Characters) suboption handler because add_slc does not check whether the buffer is full.

https://nvd.nist.gov/vuln/detail/CVE-2025-24118

 


 

10. CVE-2025-58434

telnetd in GNU inetutils through 2.7 allows an out-of-bounds write in the LINEMODE SLC (Set Local Characters) suboption handler because add_slc does not check whether the buffer is full.

https://nvd.nist.gov/vuln/detail/CVE-2025-58434

 


"SOS
CVE Top 10

The SOS Intelligence CVE Chatter Weekly Top Ten – 29 June 2026

 

This weekly blog post is from via our unique intelligence collection pipelines. We are your eyes and ears online, including the Dark Web.

There are thousands of vulnerability discussions each week. SOS Intelligence gathers a list of the most discussed Common Vulnerabilities and Exposures (CVE) online for the previous week.

We make every effort to ensure the accuracy of the data presented. As this is an automated process some errors may creep in.

If you are feeling generous please do make us aware of anything you spot, feel free to follow us on Twitter @sosintel and DM us. Thank you!

 


 

1.  CVE-2025-59528

Windows TCP/IP Remote Code Execution Vulnerability

https://nvd.nist.gov/vuln/detail/CVE-2025-59528

 


 

2. CVE-2022-21227

Windows TCP/IP Remote Code Execution Vulnerability

https://nvd.nist.gov/vuln/detail/CVE-2022-21227

 


 

3. CVE-2026-32746

Windows TCP/IP Remote Code Execution Vulnerability

https://nvd.nist.gov/vuln/detail/CVE-2026-32746

 


 

4. CVE-2026-31431

Windows TCP/IP Remote Code Execution Vulnerability

https://nvd.nist.gov/vuln/detail/CVE-2026-31431

 


 

5. CVE-2024-34102

Windows TCP/IP Remote Code Execution Vulnerability

https://nvd.nist.gov/vuln/detail/CVE-2024-34102

 


 

6. CVE-2024-38063

Windows TCP/IP Remote Code Execution Vulnerability

https://nvd.nist.gov/vuln/detail/CVE-2024-38063

 


 

7. CVE-2024-49113

Windows TCP/IP Remote Code Execution Vulnerability

https://nvd.nist.gov/vuln/detail/CVE-2024-49113

 


 

8. CVE-2025-0368

Windows TCP/IP Remote Code Execution Vulnerability

https://nvd.nist.gov/vuln/detail/CVE-2025-0368

 


 

9. CVE-2025-14847

Windows TCP/IP Remote Code Execution Vulnerability

https://nvd.nist.gov/vuln/detail/CVE-2025-14847

 


 

10. CVE-2025-24118

Windows TCP/IP Remote Code Execution Vulnerability

https://nvd.nist.gov/vuln/detail/CVE-2025-24118

 


"SOS
CVE Top 10

The SOS Intelligence CVE Chatter Weekly Top Ten – 22 June 2026

 

This weekly blog post is from via our unique intelligence collection pipelines. We are your eyes and ears online, including the Dark Web.

There are thousands of vulnerability discussions each week. SOS Intelligence gathers a list of the most discussed Common Vulnerabilities and Exposures (CVE) online for the previous week.

We make every effort to ensure the accuracy of the data presented. As this is an automated process some errors may creep in.

If you are feeling generous please do make us aware of anything you spot, feel free to follow us on Twitter @sosintel and DM us. Thank you!

 


 

1.  CVE-2025-14876

Libsndfile <=1.2.2 contains a memory leak vulnerability in the mpeg_l3_encoder_init() function within the mpeg_l3_encode.c file.

https://nvd.nist.gov/vuln/detail/CVE-2025-14876

 


 

2. CVE-2026-27135

The OWASP core rule set (CRS) is a set of generic attack detection rules for use with compatible web application firewalls. Prior to versions 3.3.9 and 4.25.0, a bypass was identified in OWASP CRS that allows uploading files with dangerous extensions (.php, .phar, .jsp, .jspx) by inserting whitespace padding in the filename (e.g. photo. php or shell.jsp ). The affected rules do not normalize whitespace before evaluating the file extension regex, so the dot-extension check fails to match. This issue has been patched in versions 3.3.9 and 4.25.0.

https://nvd.nist.gov/vuln/detail/CVE-2026-27135

 


 

3. CVE-2026-27651

The OWASP core rule set (CRS) is a set of generic attack detection rules for use with compatible web application firewalls. Prior to versions 3.3.9 and 4.25.0, a bypass was identified in OWASP CRS that allows uploading files with dangerous extensions (.php, .phar, .jsp, .jspx) by inserting whitespace padding in the filename (e.g. photo. php or shell.jsp ). The affected rules do not normalize whitespace before evaluating the file extension regex, so the dot-extension check fails to match. This issue has been patched in versions 3.3.9 and 4.25.0.

https://nvd.nist.gov/vuln/detail/CVE-2026-27651

 


 

4. CVE-2026-27654

The OWASP core rule set (CRS) is a set of generic attack detection rules for use with compatible web application firewalls. Prior to versions 3.3.9 and 4.25.0, a bypass was identified in OWASP CRS that allows uploading files with dangerous extensions (.php, .phar, .jsp, .jspx) by inserting whitespace padding in the filename (e.g. photo. php or shell.jsp ). The affected rules do not normalize whitespace before evaluating the file extension regex, so the dot-extension check fails to match. This issue has been patched in versions 3.3.9 and 4.25.0.

https://nvd.nist.gov/vuln/detail/CVE-2026-27654

 


 

5. CVE-2026-27784

The OWASP core rule set (CRS) is a set of generic attack detection rules for use with compatible web application firewalls. Prior to versions 3.3.9 and 4.25.0, a bypass was identified in OWASP CRS that allows uploading files with dangerous extensions (.php, .phar, .jsp, .jspx) by inserting whitespace padding in the filename (e.g. photo. php or shell.jsp ). The affected rules do not normalize whitespace before evaluating the file extension regex, so the dot-extension check fails to match. This issue has been patched in versions 3.3.9 and 4.25.0.

https://nvd.nist.gov/vuln/detail/CVE-2026-27784

 


 

6. CVE-2026-28387

The OWASP core rule set (CRS) is a set of generic attack detection rules for use with compatible web application firewalls. Prior to versions 3.3.9 and 4.25.0, a bypass was identified in OWASP CRS that allows uploading files with dangerous extensions (.php, .phar, .jsp, .jspx) by inserting whitespace padding in the filename (e.g. photo. php or shell.jsp ). The affected rules do not normalize whitespace before evaluating the file extension regex, so the dot-extension check fails to match. This issue has been patched in versions 3.3.9 and 4.25.0.

https://nvd.nist.gov/vuln/detail/CVE-2026-28387

 


 

7. CVE-2026-28388

The OWASP core rule set (CRS) is a set of generic attack detection rules for use with compatible web application firewalls. Prior to versions 3.3.9 and 4.25.0, a bypass was identified in OWASP CRS that allows uploading files with dangerous extensions (.php, .phar, .jsp, .jspx) by inserting whitespace padding in the filename (e.g. photo. php or shell.jsp ). The affected rules do not normalize whitespace before evaluating the file extension regex, so the dot-extension check fails to match. This issue has been patched in versions 3.3.9 and 4.25.0.

https://nvd.nist.gov/vuln/detail/CVE-2026-28388

 


 

8. CVE-2026-28389

The OWASP core rule set (CRS) is a set of generic attack detection rules for use with compatible web application firewalls. Prior to versions 3.3.9 and 4.25.0, a bypass was identified in OWASP CRS that allows uploading files with dangerous extensions (.php, .phar, .jsp, .jspx) by inserting whitespace padding in the filename (e.g. photo. php or shell.jsp ). The affected rules do not normalize whitespace before evaluating the file extension regex, so the dot-extension check fails to match. This issue has been patched in versions 3.3.9 and 4.25.0.

https://nvd.nist.gov/vuln/detail/CVE-2026-28389

 


 

9. CVE-2026-28390

The OWASP core rule set (CRS) is a set of generic attack detection rules for use with compatible web application firewalls. Prior to versions 3.3.9 and 4.25.0, a bypass was identified in OWASP CRS that allows uploading files with dangerous extensions (.php, .phar, .jsp, .jspx) by inserting whitespace padding in the filename (e.g. photo. php or shell.jsp ). The affected rules do not normalize whitespace before evaluating the file extension regex, so the dot-extension check fails to match. This issue has been patched in versions 3.3.9 and 4.25.0.

https://nvd.nist.gov/vuln/detail/CVE-2026-28390

 


 

10. CVE-2026-28753

The OWASP core rule set (CRS) is a set of generic attack detection rules for use with compatible web application firewalls. Prior to versions 3.3.9 and 4.25.0, a bypass was identified in OWASP CRS that allows uploading files with dangerous extensions (.php, .phar, .jsp, .jspx) by inserting whitespace padding in the filename (e.g. photo. php or shell.jsp ). The affected rules do not normalize whitespace before evaluating the file extension regex, so the dot-extension check fails to match. This issue has been patched in versions 3.3.9 and 4.25.0.

https://nvd.nist.gov/vuln/detail/CVE-2026-28753

 


"SOS
CVE Top 10

The SOS Intelligence CVE Chatter Weekly Top Ten – 15 June 2026

 

This weekly blog post is from via our unique intelligence collection pipelines. We are your eyes and ears online, including the Dark Web.

There are thousands of vulnerability discussions each week. SOS Intelligence gathers a list of the most discussed Common Vulnerabilities and Exposures (CVE) online for the previous week.

We make every effort to ensure the accuracy of the data presented. As this is an automated process some errors may creep in.

If you are feeling generous please do make us aware of anything you spot, feel free to follow us on Twitter @sosintel and DM us. Thank you!

 


 

1.  CVE-2026-45185

Exim before 4.99.3, in certain GnuTLS configurations, has a remotely reachable use-after-free in the BDAT body parsing path. It is triggered when a client sends a TLS close_notify mid-body during a CHUNKING transfer, followed by a final cleartext byte on the same TCP connection. This can lead to heap corruption. An unauthenticated network attacker exploiting this vulnerability could execute arbitrary code.

https://nvd.nist.gov/vuln/detail/CVE-2026-45185

 


 

2. CVE-2026-31431

Exim before 4.99.3, in certain GnuTLS configurations, has a remotely reachable use-after-free in the BDAT body parsing path. It is triggered when a client sends a TLS close_notify mid-body during a CHUNKING transfer, followed by a final cleartext byte on the same TCP connection. This can lead to heap corruption. An unauthenticated network attacker exploiting this vulnerability could execute arbitrary code.

https://nvd.nist.gov/vuln/detail/CVE-2026-31431

 


 

3. CVE-2022-21227

Exim before 4.99.3, in certain GnuTLS configurations, has a remotely reachable use-after-free in the BDAT body parsing path. It is triggered when a client sends a TLS close_notify mid-body during a CHUNKING transfer, followed by a final cleartext byte on the same TCP connection. This can lead to heap corruption. An unauthenticated network attacker exploiting this vulnerability could execute arbitrary code.

https://nvd.nist.gov/vuln/detail/CVE-2022-21227

 


 

4. CVE-2024-34102

Exim before 4.99.3, in certain GnuTLS configurations, has a remotely reachable use-after-free in the BDAT body parsing path. It is triggered when a client sends a TLS close_notify mid-body during a CHUNKING transfer, followed by a final cleartext byte on the same TCP connection. This can lead to heap corruption. An unauthenticated network attacker exploiting this vulnerability could execute arbitrary code.

https://nvd.nist.gov/vuln/detail/CVE-2024-34102

 


 

5. CVE-2024-38063

Exim before 4.99.3, in certain GnuTLS configurations, has a remotely reachable use-after-free in the BDAT body parsing path. It is triggered when a client sends a TLS close_notify mid-body during a CHUNKING transfer, followed by a final cleartext byte on the same TCP connection. This can lead to heap corruption. An unauthenticated network attacker exploiting this vulnerability could execute arbitrary code.

https://nvd.nist.gov/vuln/detail/CVE-2024-38063

 


 

6. CVE-2024-49113

Exim before 4.99.3, in certain GnuTLS configurations, has a remotely reachable use-after-free in the BDAT body parsing path. It is triggered when a client sends a TLS close_notify mid-body during a CHUNKING transfer, followed by a final cleartext byte on the same TCP connection. This can lead to heap corruption. An unauthenticated network attacker exploiting this vulnerability could execute arbitrary code.

https://nvd.nist.gov/vuln/detail/CVE-2024-49113

 


 

7. CVE-2025-0368

Exim before 4.99.3, in certain GnuTLS configurations, has a remotely reachable use-after-free in the BDAT body parsing path. It is triggered when a client sends a TLS close_notify mid-body during a CHUNKING transfer, followed by a final cleartext byte on the same TCP connection. This can lead to heap corruption. An unauthenticated network attacker exploiting this vulnerability could execute arbitrary code.

https://nvd.nist.gov/vuln/detail/CVE-2025-0368

 


 

8. CVE-2025-14847

Exim before 4.99.3, in certain GnuTLS configurations, has a remotely reachable use-after-free in the BDAT body parsing path. It is triggered when a client sends a TLS close_notify mid-body during a CHUNKING transfer, followed by a final cleartext byte on the same TCP connection. This can lead to heap corruption. An unauthenticated network attacker exploiting this vulnerability could execute arbitrary code.

https://nvd.nist.gov/vuln/detail/CVE-2025-14847

 


 

9. CVE-2025-21204

Exim before 4.99.3, in certain GnuTLS configurations, has a remotely reachable use-after-free in the BDAT body parsing path. It is triggered when a client sends a TLS close_notify mid-body during a CHUNKING transfer, followed by a final cleartext byte on the same TCP connection. This can lead to heap corruption. An unauthenticated network attacker exploiting this vulnerability could execute arbitrary code.

https://nvd.nist.gov/vuln/detail/CVE-2025-21204

 


 

10. CVE-2025-24118

Exim before 4.99.3, in certain GnuTLS configurations, has a remotely reachable use-after-free in the BDAT body parsing path. It is triggered when a client sends a TLS close_notify mid-body during a CHUNKING transfer, followed by a final cleartext byte on the same TCP connection. This can lead to heap corruption. An unauthenticated network attacker exploiting this vulnerability could execute arbitrary code.

https://nvd.nist.gov/vuln/detail/CVE-2025-24118

 


Investigation

De-anonymising Tor Hidden Services: How Misconfigurations Expose the Dark Web

Introduction

Tor hidden services exist for one reason: anonymity. The entire architecture of onion routing is designed to ensure that a visitor cannot determine where a service is physically hosted, and that the hosting provider’s real IP address never leaks. In theory, this makes hidden services untraceable. In practice, it does not.

The gap between theory and practice is where threat intelligence gets interesting. Over the past decade, researchers, law enforcement, and OSINT practitioners have demonstrated repeatedly that the anonymity of Tor hidden services can be undermined not by breaking the cryptography or the network protocol, but by exploiting something far simpler: misconfiguration.

At SOS Intelligence, we crawl and index dark web content continuously through our DARKSEARCH platform. As part of that work, we encounter misconfigured hidden services regularly. Some expose their real server IP addresses through default web server configurations. Others leak identifying information through debug pages, status endpoints, or metadata embedded in the content they serve. In this article, we will walk through the most common ways that Tor hidden services inadvertently reveal their clearweb identity, how intelligence analysts can use these techniques ethically, and what this means for anyone running or monitoring hidden services.

De-anonymising Tor Hidden Services: How Misconfigurations Expose the Dark Web

How Tor Hidden Services Are Supposed to Work

Before we get into the failures, it is worth understanding what a properly configured hidden service looks like. When a Tor hidden service is set up correctly, the web server (Apache, Nginx, or whatever is being used) binds exclusively to localhost, typically 127.0.0.1. The Tor daemon running on the same machine creates a virtual tunnel, accepting incoming connections from the Tor network and forwarding them to the local web server.

The critical point is that the web server should never be listening on a public-facing IP address. If it only listens on 127.0.0.1, the only way to reach it is through the Tor daemon. The server’s real IP address is never exposed to the visitor because the visitor’s traffic is routed through the Tor network and terminates at the Tor daemon, not at the web server directly.

This is the theory. The reality is that many hidden service operators, whether through ignorance, laziness, or haste, fail to configure their servers this way. And when they fail, they leave behind digital breadcrumbs that can be followed all the way back to a clearweb IP address, a hosting provider, and often a physical location.

The Classic: Apache mod_status

The most well-documented and arguably most devastating misconfiguration involves Apache’s mod_status module. This has been a known issue since at least 2001, but it continues to surface on Tor hidden services in 2026.

So here is how it works. On most Linux distributions, Apache ships with mod_status enabled by default. This module provides a real-time status page at /server-status that displays diagnostic information about the running web server. The information it exposes includes the server’s uptime, current connections, the IP addresses of connected clients, the URLs being requested, virtual host configurations, and critically, the server name and IP address of the machine itself.

On a standard ClearWeb server, access to /server-status is typically restricted to localhost or specific IP ranges via Apache’s configuration. But here is where the misconfiguration occurs: when the Tor daemon forwards traffic to the local Apache instance, that traffic arrives from 127.0.0.1 (because the Tor daemon is local). This means it passes the default access restriction. The /server-status page becomes accessible to anyone connecting via Tor.

What Gets Exposed

When an analyst successfully accesses /server-status on a misconfigured Tor hidden service, the data returned can be remarkably detailed. The server name field often contains the server’s real hostname, which may resolve directly to a clearweb IP. The virtual host configuration can reveal other domains being hosted on the same machine. Active connection details may show clearweb IP addresses of other visitors or the server’s own outbound connections. In some cases, the page reveals the exact Apache version, operating system, and loaded modules, giving a complete fingerprint of the server.

During our DARKSEARCH crawls, we have identified numerous Tor hidden services returning Apache error pages (403 Forbidden, 404 Not Found) that include server signature information in the response headers:

  • hxxp://cii64fki62v2mudocjvgarzlmnpqrfp6xb7korapmdd7qmjpnccgduyd[.]onion
    • returned a standard 403 Forbidden page during our crawl on 3 March 2026, including the server signature in the response.
  • hxxp://hmxt5u75kj5qxqjqhckgaoda6zndgxcazleersyioat4iuq3ldgmkcid[.]onion and hxxp://pbbeck4xcy3jzbu6lv5db3c5n3n44wngmpb5jj3yo4px32mlznziwbid[.]onion
    • displayed similar Apache error patterns.

While these are less severe than a fully exposed /server-status page, they still leak server version information that can be cross-referenced with Shodan, Censys, or similar clearweb scanning databases to narrow down the server’s identity.

Real-World Prevalence

PHP Information Disclosure: phpinfo() and Friends

PHP’s built-in phpinfo() function is another classic source of information leaks on Tor hidden services. Developers routinely create test pages (often info.php, phpinfo.php, or test.php) that call phpinfo() to verify their server configuration. The problem is that these pages are frequently left in production, and on a hidden service, they can be accessed by anyone.

The phpinfo() output is extraordinarily detailed. It includes the server’s IP address (in the SERVER_ADDR variable), the server’s hostname (SERVER_NAME), the document root path (which may contain revealing directory structures), all loaded PHP extensions, environment variables that may contain database credentials or API keys, and the exact PHP and operating system versions.

The SERVER_ADDR field is particularly damaging. On a properly configured hidden service, this should show 127.0.0.1. But if the web server is bound to a public IP (the misconfiguration we keep coming back to), SERVER_ADDR will show the server’s real clearweb IP address, directly. No correlation or inference required.

Searching for phpinfo() Pages

Using our DARKSEARCH API, analysts can search for common phpinfo page titles and content patterns across indexed Tor content. The search is straightforward: look for pages containing strings like ‘PHP Version’, ‘SERVER_ADDR’, ‘DOCUMENT_ROOT’, or the characteristic phpinfo() HTML table structure. Our crawls regularly index pages that match these patterns across the onion network.

Beyond phpinfo(), similar information can be leaked by debug frameworks and error reporting configurations. PHP applications running in development mode may display detailed stack traces that include file paths, database connection strings, and server IP addresses. Laravel’s debug page, for instance, is notorious for exposing the full application configuration, including environment variables, when APP_DEBUG is set to true.

SSL/TLS Certificate Leaks

This is one of the more elegant de-anonymisation techniques and was documented extensively by researcher Yonathan Klijnsma. The core issue is that some hidden service operators install SSL/TLS certificates on their Tor-hosted web servers, often for the same domain they use on the clearweb.

So when a hidden service operator obtains an SSL certificate (whether from Let’s Encrypt, Comodo, or any other CA), that certificate is logged in public Certificate Transparency (CT) logs. These logs are searchable using tools like crt.sh. If the same certificate is used on both the hidden service and a clearweb server, or if the certificate’s Subject Alternative Names (SANs) include the server’s clearweb domain, the link between the .onion address and the clearweb identity becomes trivial to establish.

Even without direct domain overlap, the certificate itself contains metadata. The organisation name, the country, the issuance date, and the certificate serial number can all be used as pivot points. Cross-referencing certificate fingerprints with databases like crt.sh, Censys, or Shodan’s SSL certificate search can reveal other services using the same certificate, potentially including clearweb servers.

Why This Keeps Happening

The reason this misconfiguration persists is partly a misunderstanding of what SSL does in the context of Tor. The Tor protocol already encrypts traffic between the client and the hidden service. Adding SSL on top of this does not improve security in any meaningful way for a .onion service. But operators who are accustomed to clearweb hosting habits often install SSL certificates out of habit or because their web application framework requires HTTPS.

The more dangerous scenario is when an operator runs a dual-stack configuration: the same server hosts both a clearweb site and a hidden service. If the SSL certificate covers both, the link is immediate. But even single-stack hidden services can be compromised if the certificate was previously used on a clearweb server, because CT logs are permanent.

Default Pages, Error Messages, and Server Signatures

Not every de-anonymisation technique requires accessing a special endpoint. Sometimes, the information leaks from the most basic server responses.

Default Installation Pages

When our DARKSEARCH crawlers encounter a Tor hidden service showing the default Nginx welcome page, the default Apache test page, or a framework’s default landing page, this tells us several things. First, the operator likely set up the service quickly and did not complete the configuration. Second, the default page often reveals the exact server software version. Third, the default configuration files associated with these pages may have additional endpoints enabled (like /server-status for Apache or /stub_status for Nginx).

We have observed this pattern repeatedly in our crawl data. Onion addresses serving generic 403 Forbidden or 404 Not Found pages with Apache or Nginx signatures in the response body are surprisingly common:

  • hxxp://eme7o5bdqwsqvdcj4j6ore6exvxnh6jv3d3nkieopmxfbmdxtrhiljqd[.]onion
    • Returned a 404 Not Found message stating ‘Not Found. The requested URL was not found on this server.’ with clear server identification in the response headers, indexed during our March 2026 DARKSEARCH crawl.

Each of these reveals the web server software and often the version number, which becomes a fingerprint.

Verbose Error Pages

Application-level errors can be even more revealing. A misconfigured Django application will display a detailed debug page showing the settings module, installed middleware, database engine, and file paths. A Node.js application crashing with an unhandled exception may dump stack traces containing absolute file paths. A misconfigured PHP application might display MySQL connection errors that include the database host (which could be a clearweb IP if the database is hosted externally).

Each of these error patterns provides pivot points. File paths can reveal operating system details and directory structures. Database connection strings can point to external clearweb services. Stack traces can reveal the application framework and version, which can be correlated with publicly accessible source code repositories.

HTTP Response Headers

Even when the page content itself reveals nothing, the HTTP response headers can leak information. Common leaky headers include X-Powered-By (reveals the backend technology), Server (reveals the web server and version), X-AspNet-Version (reveals the .NET framework version), and custom headers that may include internal hostnames or IP addresses. The Via header, used by proxies, can sometimes reveal the chain of servers the request passed through, potentially including clearweb infrastructure.

Exposed Administration Interfaces

One of the most directly exploitable categories of misconfiguration involves web-based administration panels that were intended to be accessible only from localhost but end up being exposed via the Tor service.

Common Exposed Services

The pattern here is consistent. Services that bind to 0.0.0.0 (all interfaces) by default become accessible through Tor when the hidden service is configured to forward traffic to the server’s local port. An operator who sets up a hidden service and also runs phpMyAdmin for database management may not realise that phpMyAdmin is now accessible to the entire Tor network.

During our research, we found numerous onion addresses serving content that strongly suggests exposed administration interfaces. WordPress login pages on hidden services, for example, are extremely common in our DARKSEARCH index. While a WordPress login page alone does not expose a clearweb IP, the WordPress installation itself may contain metadata (in uploaded images, in theme files, in plugin configurations) that references clearweb URLs. We also observed directory listing capabilities on some services:

  • hxxp://ylf6u5gurfisvhgheevy4rxzcw36gyp4r55crqlmiydmzwi2xkvmhcad[.]onion
    • (Go Go Onion directory)
  • hxxp://wikipenntwqezw7ycy72zmblcxh6fodtqb6yyyfyz55uoh4fx6wqciid[.]onion
    • (HiddenWiki)

which index and expose other onion services and their details.

Metadata and Content-Based Leaks

Beyond server configuration issues, the content hosted on a hidden service can itself contain identifying information.

EXIF Data in Images

Images uploaded to hidden services may contain EXIF metadata including GPS coordinates, camera make and model, software used to process the image, timestamps, and in some cases, the original filename that may reference a clearweb domain or username. Tools like OnionScan, developed by Sarah Jamie Lewis, specifically check for EXIF data in images hosted on hidden services. Our DARKSEARCH platform includes a similar capability, allowing analysts to identify images with residual metadata that can be correlated with clearweb sources.

Embedded Clearweb Resources

A hidden service page that loads JavaScript libraries, CSS stylesheets, images, or fonts from clearweb CDNs creates a tracking vector. When a visitor loads the hidden service page, their browser (or, in our case, our crawler) can observe the external resource requests. More importantly, the CDN operator can log the timing of those requests, and the hidden service operator has implicitly revealed that they control the account on the CDN from which the resources are served.

The reverse is also true: if a hidden service’s HTML source contains hardcoded clearweb URLs (perhaps the developer copied the template from their clearweb site), those URLs can directly identify the operator. We have seen this in our crawls, where onion-hosted pages reference clearweb domains in their source code, style sheets, or embedded scripts:

  • hxxp://bfdxjkv5e2z3ilrifzbnvxxvhbzsj67akjpj3zc6smzr4vv6oz565gyd[.]onion
    • (observed as a XenForo forum)
  • hxxp://33333337u3npxstc4rrx2z2o5z5cvmbbdr4maqzlutpgmgcqobnxxuqd[.]onion
    • (VicePaste service)

sometimes reveal resource references in their indexable content.

DNS Leaks

If the hidden service’s server makes outbound DNS requests (for example, to resolve a database server hostname, to check for updates, or to load external content), those DNS queries go through the server’s regular network stack, not through Tor. An observer with access to the DNS infrastructure can see the server’s real IP address, making those queries. This is not directly detectable through our DARKSEARCH crawls, but it is a significant vector that complements the other techniques discussed here.

Using the SOS Intelligence API for Tor Service Analysis

At SOS Intelligence, our DARKSEARCH API provides programmatic access to our indexed dark web content, including Tor hidden service data. Analysts can use this to systematically search for the misconfiguration patterns described in this article.

DARKSEARCH Endpoint

The DARKSEARCH endpoint (GET /api/v2/darksearch/new) accepts search queries and returns indexed content from Tor hidden services. By searching for terms like ‘server-status’, ‘phpinfo’, ‘wp-login’, or specific error message patterns, analysts can identify potentially misconfigured services at scale. Each result includes the onion hostname, the page title, the indexed content, and timestamps showing when the page was crawled.

Practical Search Patterns

Tor Metadata Endpoints

Beyond DARKSEARCH, our Tor API endpoints provide metadata about onion services, including path information that can reveal directory structures and exposed endpoints. By analysing the paths crawled on a given onion service, analysts can identify non-standard endpoints that may correspond to administrative interfaces or debug pages.

Defensive Guidance: Hardening Hidden Services

While this article has focused on offensive OSINT techniques, the defensive side is equally important. If your organisation runs legitimate hidden services (for example, for secure whistleblowing, censorship circumvention, or privacy-preserving communication), the following configuration practices are essential.

Web Server Configuration

Bind to localhost only. Your web server must listen exclusively on 127.0.0.1. In Apache, this means setting Listen 127.0.0.1:80 in the main configuration. In Nginx, use listen 127.0.0.1:80. Never use 0.0.0.0 or *.

Disable mod_status and mod_info. In Apache, explicitly disable these modules with a2dismod status and a2dismod info. Do not rely on access controls alone.

Remove default pages and test files. Delete index.html default pages, phpinfo.php test files, and any other diagnostic scripts before going live.

Suppress server signatures. In Apache, set ServerTokens Prod and ServerSignature Off. In Nginx, add server_tokens off to the http block.

Strip revealing headers. Remove X-Powered-By and other headers that reveal your technology stack.

Application Configuration

Never run in debug or development mode. Ensure your application is running in production mode with detailed error reporting disabled for end users.

Do not use SSL certificates. Tor already provides end-to-end encryption. Adding SSL to a hidden service only creates a de-anonymisation vector through Certificate Transparency logs.

Avoid loading external resources. Host all JavaScript, CSS, fonts, and images locally. Do not reference clearweb CDNs.

Strip EXIF data from images. Process all uploaded images to remove metadata before serving them.

Infrastructure Security

Isolate the hidden service. Run it in a dedicated container or VM that has no other services exposed. Do not host a clearweb site and a hidden service on the same machine.

Block outbound connections. Configure firewall rules so the hidden service machine can only communicate through Tor. This prevents DNS leaks and outbound connections that could reveal the real IP.

Audit regularly. Use tools like OnionScan to check your own hidden service for information leaks. Treat this as part of your regular security review process.

The Intelligence Value of Misconfigured Services

For threat intelligence teams, the techniques described in this article are not theoretical. They produce actionable results. When a dark web marketplace, ransomware leak site, or fraud operation is hosted on a misconfigured Tor hidden service, the exposed clearweb IP can lead to a hosting provider, a jurisdiction, and potentially an individual.

Even partial information has value. A server version fingerprint can narrow the search space from billions of IPs to thousands. A leaked hostname can be resolved and cross-referenced. A certificate fingerprint can be tracked across multiple services. An exposed admin panel username can be correlated with clearweb accounts. The cumulative effect of multiple small leaks is often enough to identify the operator.

Law enforcement agencies have used exactly these techniques in major dark web takedowns. The Silk Road investigation benefited from a server misconfiguration that leaked the site’s IP address via its CAPTCHA server. The Hansa Market takedown involved Dutch National Police exploiting similar configuration errors to identify and eventually operate the marketplace. These are not exotic attacks. They are straightforward OSINT techniques applied to poorly configured servers.

Appendix: Observed Indicators from DARKSEARCH

The following table documents real onion addresses observed during DARKSEARCH crawls in March 2026 that exhibit the misconfiguration patterns discussed in this article. These services were indexed through our standard crawling process and represent active examples of the threat vectors described throughout this report. All onion addresses are defanged for security purposes (dots replaced with [.]).

The presence of these indicators in our DARKSEARCH index demonstrates that misconfiguration de-anonymisation techniques remain effective against real-world Tor hidden services. Each category of indicator (error page signatures, directory listings, resource references) represents a distinct attack vector that threat intelligence teams can operationalise at scale using the DARKSEARCH API.

External References and Tools

The following resources provide additional context, methodologies, and tooling for Tor hidden service analysis and de-anonymisation research:

Academic and Research Papers

  • Klijnsma, Y. (2015). ‘HTTPS: The Wrong Side of History’ documented SSL certificate de-anonymisation techniques and Certificate Transparency log analysis methods for identifying hidden service operators.
  • Lewis, S. J. (2014). ‘OnionScan: Automated OSINT for Tor Hidden Services’ introduced methodologies for systematic scanning and metadata extraction from onion services.

Law Enforcement Case Studies

  • Silk Road Investigation: Federal law enforcement identified Ross Ulbricht’s infrastructure partly through misconfiguration vectors, including a CAPTCHA server that leaked IP address information due to poor isolation from the Tor service.
  • Hansa Market Takedown: Dutch National Police (Politie) identified and eventually operated the Hansa marketplace by exploiting similar misconfiguration patterns, including exposed administrative interfaces and information disclosure vulnerabilities.

Publicly Available Tools

  • OnionScan (by Sarah Jamie Lewis): Automated tool for scanning Tor hidden services and extracting metadata, EXIF data, and server information. Source available on GitHub.
  • crt.sh: Certificate Transparency search engine allowing analysts to query public CT logs for SSL certificates. Useful for linking .onion services to clearweb domains.
  • Shodan (shodan.io): Internet-wide scanning database that indexes server banners, headers, and metadata. Can be used to cross-reference server fingerprints and configurations.
  • Censys: Internet scanning and certificate database providing similar capabilities to Shodan, with particular strength in certificate transparency log analysis.
  • DARKSEARCH API (SOS Intelligence): Programmatic access to indexed dark web content, including Tor hidden services. Supports systematic searching for misconfiguration patterns and metadata extraction.

Related Reading

  • Greensill, J. & Aldridge, J. (2019). ‘Cryptomarkets and the Future of Illicit Drug Markets’ discusses operational security practices and common failures of dark web services.
  • NIST Cybersecurity Framework: Provides defensive guidance for organisation-wide security hardening, including principles applicable to Tor hidden service deployment.

Conclusion

The anonymity provided by Tor is only as strong as the weakest configuration on the server. The Tor network itself remains robust, but the humans running hidden services make mistakes. They leave debug pages enabled. They install SSL certificates that link back to their identity. They run web servers with default configurations that expose status pages. They load resources from clearweb CDNs. They forget to strip metadata from images.

For threat intelligence professionals, these mistakes are opportunities. They provide a way to peer behind the curtain of anonymity and identify the infrastructure, and sometimes the individuals, behind dark web operations. The techniques are well-documented, the tools are freely available, and the results are frequently actionable.

At SOS Intelligence, we provide the raw data and search capability that makes this kind of analysis possible at scale. Our DARKSEARCH platform indexes dark web content continuously, and our API gives analysts programmatic access to search for the exact patterns described in this article. If you are running a threat intelligence programme, and you are not systematically checking for these misconfigurations, you are missing intelligence.

Header photo by Rafael Garcin on Unsplash.

Hidden door photo by Stefan Steinbauer on Unsplash

"SOS
CVE Top 10

The SOS Intelligence CVE Chatter Weekly Top Ten – 08 June 2026

 

This weekly blog post is from via our unique intelligence collection pipelines. We are your eyes and ears online, including the Dark Web.

There are thousands of vulnerability discussions each week. SOS Intelligence gathers a list of the most discussed Common Vulnerabilities and Exposures (CVE) online for the previous week.

We make every effort to ensure the accuracy of the data presented. As this is an automated process some errors may creep in.

If you are feeling generous please do make us aware of anything you spot, feel free to follow us on Twitter @sosintel and DM us. Thank you!

 


 

1.  CVE-2026-31431

In the Linux kernel, the following vulnerability has been resolved:

crypto: algif_aead – Revert to operating out-of-place

This mostly reverts commit 72548b093ee3 except for the copying of
the associated data.

There is no benefit in operating in-place in algif_aead since the
source and destination come from different mappings. Get rid of
all the complexity added for in-place operation and just copy the
AD directly.

https://nvd.nist.gov/vuln/detail/CVE-2026-31431

 


 

2. CVE-2026-45185

Deserialization of untrusted data in Windows Server Update Service allows an unauthorized attacker to execute code over a network.

https://nvd.nist.gov/vuln/detail/CVE-2026-45185

 


 

3. CVE-2025-50708

Deserialization of untrusted data in Windows Server Update Service allows an unauthorized attacker to execute code over a network.

https://nvd.nist.gov/vuln/detail/CVE-2025-50708

 


 

4. CVE-2024-34102

Deserialization of untrusted data in Windows Server Update Service allows an unauthorized attacker to execute code over a network.

https://nvd.nist.gov/vuln/detail/CVE-2024-34102

 


 

5. CVE-2024-38063

Deserialization of untrusted data in Windows Server Update Service allows an unauthorized attacker to execute code over a network.

https://nvd.nist.gov/vuln/detail/CVE-2024-38063

 


 

6. CVE-2024-49113

Deserialization of untrusted data in Windows Server Update Service allows an unauthorized attacker to execute code over a network.

https://nvd.nist.gov/vuln/detail/CVE-2024-49113

 


 

7. CVE-2026-32746

Deserialization of untrusted data in Windows Server Update Service allows an unauthorized attacker to execute code over a network.

https://nvd.nist.gov/vuln/detail/CVE-2026-32746

 


 

8. CVE-2025-0368

Deserialization of untrusted data in Windows Server Update Service allows an unauthorized attacker to execute code over a network.

https://nvd.nist.gov/vuln/detail/CVE-2025-0368

 


 

9. CVE-2022-21227

Deserialization of untrusted data in Windows Server Update Service allows an unauthorized attacker to execute code over a network.

https://nvd.nist.gov/vuln/detail/CVE-2022-21227

 


 

10. CVE-2021-40539

Deserialization of untrusted data in Windows Server Update Service allows an unauthorized attacker to execute code over a network.

https://nvd.nist.gov/vuln/detail/CVE-2021-40539

 


"SOS
CVE Top 10

The SOS Intelligence CVE Chatter Weekly Top Ten – 01 June 2026

 

This weekly blog post is from via our unique intelligence collection pipelines. We are your eyes and ears online, including the Dark Web.

There are thousands of vulnerability discussions each week. SOS Intelligence gathers a list of the most discussed Common Vulnerabilities and Exposures (CVE) online for the previous week.

We make every effort to ensure the accuracy of the data presented. As this is an automated process some errors may creep in.

If you are feeling generous please do make us aware of anything you spot, feel free to follow us on Twitter @sosintel and DM us. Thank you!

 


 

1.  CVE-2026-45185

Adobe Commerce versions 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8 and earlier are affected by an Improper Restriction of XML External Entity Reference (‘XXE’) vulnerability that could result in arbitrary code execution. An attacker could exploit this vulnerability by sending a crafted XML document that references external entities. Exploitation of this issue does not require user interaction.

https://nvd.nist.gov/vuln/detail/CVE-2026-45185

 


 

2. CVE-2025-68613

Adobe Commerce versions 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8 and earlier are affected by an Improper Restriction of XML External Entity Reference (‘XXE’) vulnerability that could result in arbitrary code execution. An attacker could exploit this vulnerability by sending a crafted XML document that references external entities. Exploitation of this issue does not require user interaction.

https://nvd.nist.gov/vuln/detail/CVE-2025-68613

 


 

3. CVE-2021-40539

Adobe Commerce versions 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8 and earlier are affected by an Improper Restriction of XML External Entity Reference (‘XXE’) vulnerability that could result in arbitrary code execution. An attacker could exploit this vulnerability by sending a crafted XML document that references external entities. Exploitation of this issue does not require user interaction.

https://nvd.nist.gov/vuln/detail/CVE-2021-40539

 


 

4. CVE-2022-21227

Adobe Commerce versions 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8 and earlier are affected by an Improper Restriction of XML External Entity Reference (‘XXE’) vulnerability that could result in arbitrary code execution. An attacker could exploit this vulnerability by sending a crafted XML document that references external entities. Exploitation of this issue does not require user interaction.

https://nvd.nist.gov/vuln/detail/CVE-2022-21227

 


 

5. CVE-2024-34102

Adobe Commerce versions 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8 and earlier are affected by an Improper Restriction of XML External Entity Reference (‘XXE’) vulnerability that could result in arbitrary code execution. An attacker could exploit this vulnerability by sending a crafted XML document that references external entities. Exploitation of this issue does not require user interaction.

https://nvd.nist.gov/vuln/detail/CVE-2024-34102

 


 

6. CVE-2024-38063

Adobe Commerce versions 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8 and earlier are affected by an Improper Restriction of XML External Entity Reference (‘XXE’) vulnerability that could result in arbitrary code execution. An attacker could exploit this vulnerability by sending a crafted XML document that references external entities. Exploitation of this issue does not require user interaction.

https://nvd.nist.gov/vuln/detail/CVE-2024-38063

 


 

7. CVE-2024-49113

Adobe Commerce versions 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8 and earlier are affected by an Improper Restriction of XML External Entity Reference (‘XXE’) vulnerability that could result in arbitrary code execution. An attacker could exploit this vulnerability by sending a crafted XML document that references external entities. Exploitation of this issue does not require user interaction.

https://nvd.nist.gov/vuln/detail/CVE-2024-49113

 


 

8. CVE-2025-0368

Adobe Commerce versions 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8 and earlier are affected by an Improper Restriction of XML External Entity Reference (‘XXE’) vulnerability that could result in arbitrary code execution. An attacker could exploit this vulnerability by sending a crafted XML document that references external entities. Exploitation of this issue does not require user interaction.

https://nvd.nist.gov/vuln/detail/CVE-2025-0368

 


 

9. CVE-2025-14847

Adobe Commerce versions 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8 and earlier are affected by an Improper Restriction of XML External Entity Reference (‘XXE’) vulnerability that could result in arbitrary code execution. An attacker could exploit this vulnerability by sending a crafted XML document that references external entities. Exploitation of this issue does not require user interaction.

https://nvd.nist.gov/vuln/detail/CVE-2025-14847

 


 

10. CVE-2025-21204

Adobe Commerce versions 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8 and earlier are affected by an Improper Restriction of XML External Entity Reference (‘XXE’) vulnerability that could result in arbitrary code execution. An attacker could exploit this vulnerability by sending a crafted XML document that references external entities. Exploitation of this issue does not require user interaction.

https://nvd.nist.gov/vuln/detail/CVE-2025-21204

 


1 2 3 4 … 33 34
New: Attack Surface Management · Dark web intelligence. Now with the bigger picture. | Explore SOS Intelligence ASM →
Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Youtube
Consent to display content from - Youtube
Vimeo
Consent to display content from - Vimeo
Google Maps
Consent to display content from - Google
Spotify
Consent to display content from - Spotify
Sound Cloud
Consent to display content from - Sound