Ranked by attention across researchers, advisories, exploit references, and community discussion. Higher rank means more live signal, not a higher CVSS by default. Use search and sort to compare strength and recency.
Vendors by Exposure
Select to apply CPE scope
Products by Exposure: splunk
Narrow scope by product
Attention over time (30D)
Mention volume for the top 11 CVEs in this view. Toggle series to compare momentum.
10/11 CVEs visible
Threat signal metrics
45,233
CVEs in scope
141,308
Signal volume
497
24h volume
24,284
Active exploitation
38,689
Patches / workarounds
Aggregate signal volume (30D)
Total mentions across in-scope CVEs. Spikes usually track advisories, PoC chatter, or exploitation reporting, not random drift.
Signal classification
Where discussion is coming from. Useful context when a CVE suddenly dominates a category.
Disclosure61,249(46.1%)
Patch24,007(18.1%)
Active Exploitation22,570(17.0%)
General19,817(14.9%)
PoC5,147(3.9%)
Threat indicators
PoC references, exploit code, active exploitation, patches, and technical detail, aggregated for the current scope.
Technical Details99,628(55.8%)
Patch Available38,689(21.7%)
Active Exploitation24,284(13.6%)
PoC Mentioned11,164(6.2%)
Exploit Code4,867(2.7%)
> pipeline.stream (live)
How it works
One post becomes signal: watch it move through ingest → classify → enrich → route.
Pipeline stage 1 of 4: Ingest signals
Ingestcapture
Classifytag + score
Enrichcontext
Emitroute
Simo @SimoKohonen
Example post · pipeline demo
Webshells be flowing into Cisco SD-WAN honeypots now..
Exploitation of CVE-2026-20127 is looking pretty heavy, new actors popping up by the hour
We collect and classify mentions across channels that move before tickets do: advisories, researcher posts, exploit references, and technical discussion.
[ 02 ]
Score attention
CVEs surface by signal volume and trajectory, not a static severity label, so spikes in discussion map to spikes in urgency.
[ 03 ]
Surface threat context
Exploit momentum, PoC noise, active exploitation flags, and patch availability appear alongside each CVE so triage is factual, not guesswork.
[ 04 ]
Scope to your stack
Filter by vendor and product (Microsoft, Apple, Cisco, and more) so the feed reflects exposure you actually run, not the entire internet’s backlog.
> loop: raw social post → classify → enrich with threat context → emit to your scoped feed
About VulnSocial
VulnSocial is not a generic scanner. We aggregate and classify vulnerability signals from the channels that move first: researchers, advisories, exploit references, and community discussion. CVEs are ordered by attention and momentum, not CVSS alone. Active exploitation indicators, PoC noise, and patch availability sit next to each CVE so triage is grounded in what is happening now.
Scope the dashboard with vendor and product filters to match your stack. Security teams use VulnSocial to cut through alert fatigue: SOC analysts for ranked triage, leads for credible briefings, DevSecOps for stack-specific trending and remediation timing. Share snapshots with your team from the feed when you need to align on what matters today.
VULNSOCIAL
splunk/splunkFix what matters first
Ranked by live signal for this scope. Use the feed below to prioritize fixes.
Ranked by attention across researchers, advisories, exploit references, and community discussion. Higher rank means more live signal, not a higher CVSS by default. Use search and sort to compare strength and recency.
Vendors by Exposure
Select to apply CPE scope
Products by Exposure: splunk
Narrow scope by product
Attention over time (30D)
Mention volume for the top 11 CVEs in this view. Toggle series to compare momentum.
10/11 CVEs visible
Threat signal metrics
45,233
CVEs in scope
141,308
Signal volume
497
24h volume
24,284
Active exploitation
38,689
Patches / workarounds
Aggregate signal volume (30D)
Total mentions across in-scope CVEs. Spikes usually track advisories, PoC chatter, or exploitation reporting, not random drift.
Signal classification
Where discussion is coming from. Useful context when a CVE suddenly dominates a category.
Disclosure61,249(46.1%)
Patch24,007(18.1%)
Active Exploitation22,570(17.0%)
General19,817(14.9%)
PoC5,147(3.9%)
Threat indicators
PoC references, exploit code, active exploitation, patches, and technical detail, aggregated for the current scope.
Technical Details99,628(55.8%)
Patch Available38,689(21.7%)
Active Exploitation24,284(13.6%)
PoC Mentioned11,164(6.2%)
Exploit Code4,867(2.7%)
> pipeline.stream (live)
How it works
One post becomes signal: watch it move through ingest → classify → enrich → route.
Pipeline stage 1 of 4: Ingest signals
Ingestcapture
Classifytag + score
Enrichcontext
Emitroute
Simo @SimoKohonen
Example post · pipeline demo
Webshells be flowing into Cisco SD-WAN honeypots now..
Exploitation of CVE-2026-20127 is looking pretty heavy, new actors popping up by the hour
We collect and classify mentions across channels that move before tickets do: advisories, researcher posts, exploit references, and technical discussion.
[ 02 ]
Score attention
CVEs surface by signal volume and trajectory, not a static severity label, so spikes in discussion map to spikes in urgency.
[ 03 ]
Surface threat context
Exploit momentum, PoC noise, active exploitation flags, and patch availability appear alongside each CVE so triage is factual, not guesswork.
[ 04 ]
Scope to your stack
Filter by vendor and product (Microsoft, Apple, Cisco, and more) so the feed reflects exposure you actually run, not the entire internet’s backlog.
> loop: raw social post → classify → enrich with threat context → emit to your scoped feed
About VulnSocial
VulnSocial is not a generic scanner. We aggregate and classify vulnerability signals from the channels that move first: researchers, advisories, exploit references, and community discussion. CVEs are ordered by attention and momentum, not CVSS alone. Active exploitation indicators, PoC noise, and patch availability sit next to each CVE so triage is grounded in what is happening now.
Scope the dashboard with vendor and product filters to match your stack. Security teams use VulnSocial to cut through alert fatigue: SOC analysts for ranked triage, leads for credible briefings, DevSecOps for stack-specific trending and remediation timing. Share snapshots with your team from the feed when you need to align on what matters today.
In Splunk Enterprise versions below 10.4.3 and 10.2.7, an unauthenticated user with network access to the Patroni Representational State Transfer (REST) Application Programming Interface (API) on a search head cluster member could execute attacker-controlled operating-system commands. The vulnerability is possible because this interface does not require authentication for critical configuration operations. For more information see Sidecar configuration settings (https://help.splunk.com/en/data-management/splunk-enterprise-admin-manual/10.2/splunk-sidecars/sidecar-configuration-settings) in the Splunk documentation.
Splunk Enterprise versions 10.0.x and 9.4.x are not affected.
Improper Access Control. Splunk addressed multiple internally identified vulnerabilities in Splunk Enterprise versions 10.4.3, 10.2.7, 10.0.10, and 9.4.15. The vulnerabilities are grouped by Common Weakness Enumeration (CWE), with one Common Vulnerabilities and Exposures (CVE) identifier assigned to each group. See Details for more information.
In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user who does not hold the "admin" or "power" Splunk roles could use a user-controlled job identifier to access substantially all search job information from jobs that belong to other users, including search query text, job metadata, results, and preview results, through an Application Programming Interface (API) implemented as a Representational State Transfer (REST) API. The vulnerability is possible because the REST API does not fully validate job ownership before returning search job information.
In Splunk Enterprise versions below 10.4.3, a user that holds a role with the list_spl2_modules capability could use SQL injection in SPL2 module filtering to access all relevant data available through the affected Representational State Transfer (REST) API, including private SPL2 module definitions belonging to other users. The vulnerability is possible because Splunk Enterprise and Splunk Cloud Platform do not parameterize user-supplied values before using them in database queries for SPL2 module filtering. For more information see Manage SPL2 modules (https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/multiple-searches-in-an-spl2-module/manage-spl2-modules) and Module permissions (https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/modules-statements-and-views/module-permissions) in the Splunk documentation.
Splunk Enterprise versions 10.2.x, 10.0.x, and 9.4.x are not affected.
Improper Control of a Resource Through its Lifetime. Splunk addressed multiple internally identified vulnerabilities in Splunk Enterprise versions 10.4.3, 10.2.7, 10.0.10, and 9.4.15. The vulnerabilities are grouped by Common Weakness Enumeration (CWE), with one Common Vulnerabilities and Exposures (CVE) identifier assigned to each group. See Details for more information.
In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user who does not hold the "admin" or "power" Splunk roles could cause Splunk Secure Gateway to sign attacker-controlled payloads. The vulnerability is possible because Splunk Secure Gateway does not verify that the user is authorized to request a signature. Splunk Secure Gateway versions below 3.10.11, 3.9.25, and 3.8.72 are also affected. For more information see Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation.
Improper Neutralization. Splunk addressed multiple internally identified vulnerabilities in Splunk Enterprise versions 10.4.3, 10.2.7, 10.0.10, and 9.4.15. The vulnerabilities are grouped by Common Weakness Enumeration (CWE), with one Common Vulnerabilities and Exposures (CVE) identifier assigned to each group. See Details for more information.
In Splunk Enterprise versions below 10.4.3, 10.2.7, and 10.0.10, a low-privileged user that does not hold the "admin" or "power" Splunk roles could cause a denial of service against a Representational State Transfer (REST) API endpoint in the Discover Splunk Observability Cloud app. The vulnerability is possible because the app uses an inefficient regular expression to validate input submitted through the endpoint. For more information see About configuring role-based user access (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/about-configuring-role-based-user-access), Splunk Observability Cloud previews (https://help.splunk.com/en/splunk-enterprise/search/search-manual/10.4/observability/splunk-observability-cloud-previews), and restmap.conf (https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.4/configuration-file-reference/10.4.0-configuration-file-reference/restmap.conf) in the Splunk documentation.
Splunk Enterprise versions 9.4.x are not affected.
In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15 on Linux, a local user who can run commands as the user account running Splunk Enterprise could cause an affected Linux package upgrade to run attacker-controlled operating-system commands with root privileges. The vulnerability is possible because the Linux package maintainer script trusts existing Splunk Enterprise installation content when it performs upgrade operations with root privileges. The vulnerability requires an affected Linux package upgrade to occur after the local user modifies the installation. The local user should not be able to elevate privileges at will.
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.10, and 9.4.15, a user who does not hold the "admin" or "power" Splunk roles could create or edit scripted lookup definitions through raw configuration endpoints. The vulnerability is possible because raw transforms configuration write paths do not apply external lookup capability checks before saving scripted lookup settings.
In Splunk Enterprise versions below 10.4.3, 10.2.7, and 10.0.10, a user that holds a role with the read_o11y_content capability could inject forged entries into the app log through the Representational State Transfer (REST) API. The vulnerability is possible because Splunk App for Splunk O11y Cloud does not neutralize user-supplied SignalFlow content before writing it to the app log.
Splunk Enterprise versions 9.4.x are not affected.
In Splunk Enterprise versions below 10.4.3 and 10.2.7, an unauthenticated user with network access to the Patroni Representational State Transfer (REST) Application Programming Interface (API) on a search head cluster member could execute attacker-controlled operating-system commands. The vulnerability is possible because this interface does not require authentication for critical configuration operations. For more information see Sidecar configuration settings (https://help.splunk.com/en/data-management/splunk-enterprise-admin-manual/10.2/splunk-sidecars/sidecar-configuration-settings) in the Splunk documentation.
Splunk Enterprise versions 10.0.x and 9.4.x are not affected.
Improper Access Control. Splunk addressed multiple internally identified vulnerabilities in Splunk Enterprise versions 10.4.3, 10.2.7, 10.0.10, and 9.4.15. The vulnerabilities are grouped by Common Weakness Enumeration (CWE), with one Common Vulnerabilities and Exposures (CVE) identifier assigned to each group. See Details for more information.
In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user who does not hold the "admin" or "power" Splunk roles could use a user-controlled job identifier to access substantially all search job information from jobs that belong to other users, including search query text, job metadata, results, and preview results, through an Application Programming Interface (API) implemented as a Representational State Transfer (REST) API. The vulnerability is possible because the REST API does not fully validate job ownership before returning search job information.
In Splunk Enterprise versions below 10.4.3, a user that holds a role with the list_spl2_modules capability could use SQL injection in SPL2 module filtering to access all relevant data available through the affected Representational State Transfer (REST) API, including private SPL2 module definitions belonging to other users. The vulnerability is possible because Splunk Enterprise and Splunk Cloud Platform do not parameterize user-supplied values before using them in database queries for SPL2 module filtering. For more information see Manage SPL2 modules (https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/multiple-searches-in-an-spl2-module/manage-spl2-modules) and Module permissions (https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/modules-statements-and-views/module-permissions) in the Splunk documentation.
Splunk Enterprise versions 10.2.x, 10.0.x, and 9.4.x are not affected.
Improper Control of a Resource Through its Lifetime. Splunk addressed multiple internally identified vulnerabilities in Splunk Enterprise versions 10.4.3, 10.2.7, 10.0.10, and 9.4.15. The vulnerabilities are grouped by Common Weakness Enumeration (CWE), with one Common Vulnerabilities and Exposures (CVE) identifier assigned to each group. See Details for more information.
In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user who does not hold the "admin" or "power" Splunk roles could cause Splunk Secure Gateway to sign attacker-controlled payloads. The vulnerability is possible because Splunk Secure Gateway does not verify that the user is authorized to request a signature. Splunk Secure Gateway versions below 3.10.11, 3.9.25, and 3.8.72 are also affected. For more information see Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation.
Improper Neutralization. Splunk addressed multiple internally identified vulnerabilities in Splunk Enterprise versions 10.4.3, 10.2.7, 10.0.10, and 9.4.15. The vulnerabilities are grouped by Common Weakness Enumeration (CWE), with one Common Vulnerabilities and Exposures (CVE) identifier assigned to each group. See Details for more information.
In Splunk Enterprise versions below 10.4.3, 10.2.7, and 10.0.10, a low-privileged user that does not hold the "admin" or "power" Splunk roles could cause a denial of service against a Representational State Transfer (REST) API endpoint in the Discover Splunk Observability Cloud app. The vulnerability is possible because the app uses an inefficient regular expression to validate input submitted through the endpoint. For more information see About configuring role-based user access (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/about-configuring-role-based-user-access), Splunk Observability Cloud previews (https://help.splunk.com/en/splunk-enterprise/search/search-manual/10.4/observability/splunk-observability-cloud-previews), and restmap.conf (https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.4/configuration-file-reference/10.4.0-configuration-file-reference/restmap.conf) in the Splunk documentation.
Splunk Enterprise versions 9.4.x are not affected.
In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15 on Linux, a local user who can run commands as the user account running Splunk Enterprise could cause an affected Linux package upgrade to run attacker-controlled operating-system commands with root privileges. The vulnerability is possible because the Linux package maintainer script trusts existing Splunk Enterprise installation content when it performs upgrade operations with root privileges. The vulnerability requires an affected Linux package upgrade to occur after the local user modifies the installation. The local user should not be able to elevate privileges at will.
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.10, and 9.4.15, a user who does not hold the "admin" or "power" Splunk roles could create or edit scripted lookup definitions through raw configuration endpoints. The vulnerability is possible because raw transforms configuration write paths do not apply external lookup capability checks before saving scripted lookup settings.
In Splunk Enterprise versions below 10.4.3, 10.2.7, and 10.0.10, a user that holds a role with the read_o11y_content capability could inject forged entries into the app log through the Representational State Transfer (REST) API. The vulnerability is possible because Splunk App for Splunk O11y Cloud does not neutralize user-supplied SignalFlow content before writing it to the app log.
Splunk Enterprise versions 9.4.x are not affected.
