CVE-2026-90924

Executive Summary

CVE-2026-90924 is a critical (CVSS 9.8) use of default credentials vulnerability in Logsign SIEM, a security information and event management platform developed by Innotim Software, Telecommunications and Consultancy Trade Ltd. Co. The flaw (CWE-1392) allows an unauthenticated, network-positioned attacker to attempt common or default usernames and passwords, and successful authentication grants full confidentiality, integrity, and availability impact to the affected system. All Logsign SIEM deployments from version 6.4.101 up to (but not including) 6.4.117 are affected.

Technical Analysis

The vulnerability is classified as CWE-1392: Use of Default Credentials. This weakness class describes a situation in which a product ships with, installs, or retains a set of authentication credentials that are predetermined, widely known, or trivially guessable (e.g. "admin/admin", "root/root", "administrator/password"), and does not force or require a change before the account can be used.

In the case of Logsign SIEM, the NVD description states plainly that the product "allows Try Common or Default Usernames and Passwords." This is the entirety of the technical detail available. There is no CNA narrative, no vendor advisory text, and no researcher write-up in the provided data that describes a specific endpoint, authentication handler, parameter name, or code path.

What can be stated with confidence based on the weakness class and the CVSS vector is the following:

• The attack is network-reachable: the vector string begins AV:N, meaning no physical or adjacent-network access is required. The affected authentication interface is exposed over the network, which is consistent with a SIEM management or web console listening on a TCP port.
• The attack requires no privileges and no user interaction: PR:N and UI:N. An attacker needs no existing account and does not need to trick a legitimate user into any action.
• The attack is low complexity: AC:L. No race condition, no specialized memory grooming, no unusual preconditions. Submitting a username and password pair is, by definition, a low-complexity operation.
• The impact is total across all three pillars: C:H/I:H/A:H, with scope unchanged (S:U). A successful login to a SIEM platform yields complete read access to collected log data (confidentiality), the ability to modify configuration, alerts, and stored data (integrity), and the ability to disable or crash the platform (availability).

The affected version range is narrow: 6.4.101 through 6.4.116. This suggests the default-credential condition was either introduced or left unaddressed across a limited set of point releases in the 6.4.x branch. Because the credentials are default rather than the result of a memory-safety bug or an injection flaw, no crafted payload is required. The exploitation primitive is simply credential submission against an exposed authentication service.

Importantly, no public proof-of-concept, no Nuclei template, and no exploit code is known to exist in tracked sources. The absence of public tooling does not reduce risk, because the technique requires no tooling at all — any HTTP client or SSH client can perform it.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class (CWE-1392, use of default credentials) and the provided NVD description. No function names, endpoints, or parameters are invented here because none are disclosed in the source data.

Step 1 — Reconnaissance and target identification. An attacker enumerates internet-exposed or internally-reachable Logsign SIEM instances. Logsign is a commercial SIEM, so its web console typically presents a distinctive login page and TLS certificate. Public scanning services (Shodan, Censys, FOFA) can be queried with product- and title-based dorks to build a target list. Internal attackers — or attackers who have already gained a foothold on the corporate network via a separate initial-access vector — can perform the same enumeration with a standard port scanner against the management subnet.

Step 2 — Triggering the flaw. The attacker navigates to the Logsign SIEM authentication interface and submits a set of common or default username/password combinations. Because the weakness is CWE-1392, the credential pairs involved are the ones the product ships with or fails to force a change for. The attacker does not need to exploit a parsing bug, inject input, or bypass a cryptographic control; the product's own default account simply accepts the well-known credentials. If no account lockout, rate limiting, or MFA challenge is enforced (consistent with the AC:L and PR:N vector components), the attacker can iterate through a small dictionary of vendor-default pairs until authentication succeeds.

Step 3 — Execution at the vulnerability-class level. Execution is the successful authentication itself. The attacker obtains a valid session as a default-privileged account. In a SIEM product, default administrative accounts commonly carry the highest privilege level, giving the attacker full console access. No malicious file, script, or memory payload is delivered at this stage.

Step 4 — Post-exploitation impact. Once authenticated to a SIEM, an attacker holds one of the most valuable positions in an enterprise network. A SIEM aggregates authentication logs, firewall logs, endpoint telemetry, and often integrates with ticketing, SOAR, and directory services. Consequences include:

• Data exfiltration (C:H): bulk export of historical log data, which frequently contains internal hostnames, usernames, IP addressing, and sometimes credential material captured in log lines.
• Integrity compromise (I:H): modification or deletion of log sources, alert rules, and stored events to conceal other attacker activity; potential tampering with detection content to blind the blue team.
• Availability loss (A:H): disabling ingestion, corrupting indices, or shutting the platform down, removing the organization's central visibility.
• Pivot potential: stored integration credentials (e.g. API keys for directory services or ticketing systems) held by the SIEM can be harvested to move laterally into other systems. Note that the source data does not confirm which integrations exist in Logsign; this is a general property of SIEM platforms, not a disclosed feature of this CVE.

Because the attack is a legitimate login with valid credentials, it is difficult to distinguish from normal administrative activity without behavioral baselining.

Impact Assessment

The CVSS 3.1 base score is 9.8 (Critical) with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Breaking this down:

• Exploitability subscore is maximal. Network vector, low complexity, no privileges, no user interaction. Every metric on the exploitability side is at its most favorable value for the attacker.
• Impact subscore is maximal. Confidentiality, integrity, and availability are each rated High. Scope is Unchanged, meaning the vulnerable component and the impacted component are the same — the Logsign SIEM itself.
• Blast radius. The direct blast radius is every Logsign SIEM instance in the affected version range that remains reachable and retains default credentials. The indirect blast radius is potentially the entire monitored environment, because a SIEM is by design a central aggregation point with broad read visibility and, through integrations, broad control capability. Compromise of a SIEM is frequently treated as a worst-case scenario in incident response because it undermines the evidence base used to investigate every other incident.
• Business impact. Regulatory and compliance exposure is significant for any organization using a SIEM to satisfy logging requirements (PCI DSS, HIPAA, SOC 2, ISO 27001, NIS2). Loss of log integrity directly jeopardizes compliance attestations. Operational impact includes loss of detection and response capability during the window of compromise, and remediation cost includes full credential rotation, integration key rotation, and forensic validation of log integrity.

EPSS has not yet been scored by FIRST.org, and the CVE is not listed in CISA KEV. The absence of KEV listing means there is no confirmed evidence of exploitation in the wild at the time of writing; it does not mean exploitation is unlikely, given the trivial nature of the attack.

Detection Guidance

Detection for this CVE is fundamentally behavioral. Because the attacker authenticates with valid credentials, signature-based detection will not fire on a payload. Instead, detection must focus on authentication anomalies: logins from unexpected source IPs, logins to default or rarely-used accounts, off-hours administrative access, and post-authentication configuration changes. The rules below are written against that behavioral model and reference Logsign authentication events generically; field names may require tuning to the local log schema.

Sigma Rule

title: Logsign SIEM Successful Authentication from Unusual Source (Default Credential Abuse)
id: 8f3c1a72-4b6d-4e0a-9c21-7d5e9a1b2c34
status: experimental
description: Detects successful authentication to Logsign SIEM from a source IP not previously observed, consistent with abuse of default credentials (CVE-2026-90924).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-90924
author: valtersit.com Threat Intelligence
date: 2026/01/01
tags:
  - attack.initial_access
  - attack.t1078.001
logsource:
  product: logsign
  service: authentication
detection:
  selection:
    event_type: 'authentication_success'
    outcome: 'success'
  filter_known:
    src_ip:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  condition: selection and not filter_known
fields:
  - user
  - src_ip
  - event_type
  - outcome
falsepositives:
  - Legitimate remote administration from a new VPN egress address
  - New administrative staff connecting for the first time
level: high

YARA Rule

rule CVE_2026_90924_Logsign_Default_Cred_Config
{
    meta:
        description = "Detects Logsign SIEM configuration artifacts left at default state, indicative of CVE-2026-90924 exposure"
        author = "valtersit.com Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-90924"
        date = "2026-01-01"
        severity = "critical"

    strings:
        $logsign = "logsign" ascii nocase
        $default_user = "admin" ascii nocase
        $default_user2 = "administrator" ascii nocase
        $default_pass = "password" ascii nocase
        $default_pass2 = "changeme" ascii nocase
        $default_pass3 = "default" ascii nocase

    condition:
        $logsign and 1 of ($default_user*) and 1 of ($default_pass*)
}

Note: this YARA rule is a heuristic file-content rule intended for scanning configuration bundles or deployment artifacts, not a memory scanner signature. It will produce false positives on any file that merely mentions the word "admin" alongside "password" near the string "logsign"; treat hits as triage leads only.

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-90924 Logsign SIEM Default Credential Authentication Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"login"; nocase; http.request_body; content:"username"; nocase; http.request_body; content:"password"; nocase; threshold:type both, track by_src, count 5, seconds 60; classtype:attempted-admin; reference:cve,2026-90924; sid:9092401; rev:1;)

Note: the URI token login is a generic convention for authentication endpoints and is not a confirmed Logsign path from the supplied data. This rule requires tuning against observed Logsign traffic; it is provided as a starting template for repeated-credential-submission detection.

Elastic Detection

sequence by source.ip with maxspan=60s
  [authentication where event.outcome == "failure" and event.action == "user_login"] with runs=5
  [authentication where event.outcome == "success" and event.action == "user_login"]

This EQL sequence detects a burst of failed logins followed by a success from the same source IP, the classic signature of credential guessing against a default-credential-affected service.

Splunk SPL Query

index=logsign sourcetype=logsign:auth
| eval outcome=lower(coalesce(outcome, status, result))
| eval user=lower(coalesce(user, username, src_user))
| stats count(eval(outcome="failure")) as failures,
        count(eval(outcome="success")) as successes,
        values(user) as attempted_users,
        dc(user) as distinct_users
        by src_ip
| where failures >= 5 AND successes >= 1
| eval severity=if(distinct_users >= 3, "critical", "high")
| table src_ip, failures, successes, attempted_users, distinct_users, severity
| sort - successes

Wazuh OSSEC Rule

<group name="logsign,authentication,">
  <rule id="100924" level="0">
    <decoded_as>json</decoded_as>
    <field name="event_type">authentication</field>
    <description>Logsign SIEM authentication event (base rule).</description>
  </rule>

  <rule id="100925" level="10" frequency="5" timeframe="60">
    <if_matched_sid>100924</if_matched_sid>
    <field name="outcome">failure</field>
    <same_source_ip />
    <description>CVE-2026-90924: Repeated failed Logsign SIEM logins from same source - possible default credential guessing.</description>
    <mitre>
      <id>T1078.001</id>
    </mitre>
  </rule>

  <rule id="100926" level="12">
    <if_matched_sid>100925</if_matched_sid>
    <field name="outcome">success</field>
    <same_source_ip />
    <description>CVE-2026-90924: Successful Logsign SIEM login following repeated failures from same source - probable default credential compromise.</description>
    <mitre>
      <id>T1078.001</id>
    </mitre>
  </rule>
</group>

Field names in these rules reflect common JSON log schemas and must be mapped to the actual Logsign log format in the deployment, which is not documented in the source data.

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). The affected-version range references a "before 6.4.117" boundary, which implies that 6.4.117 may be the fixed release, but no vendor advisory, release note, or commit has been located to confirm this. Treat all guidance below as compensating controls until a vendor-confirmed fix is available.

1) Immediate mitigations (apply now):

• Identify every Logsign SIEM instance in the 6.4.101–6.4.116 range and inventory its accounts.
• Immediately rotate the password on every default, built-in, and shared account. Do not rely on changing only the obvious "admin" account; enumerate all accounts and disable those that are not required.
• Remove or disable any default account that has no legitimate owner.
• Enforce network access control: restrict the management interface to a dedicated administrative VLAN or VPN, and block internet exposure of the console entirely. Never expose a SIEM console directly to the public internet.
• Enable account lockout and login rate limiting at the application or reverse-proxy layer if the product does not provide it natively.
• Enforce multi-factor authentication on all administrative logins, including any local accounts.
• Review existing authentication logs for evidence of prior successful logins from unexpected sources, and for post-login configuration changes.

2) Patch/upgrade steps:

• Contact Innotim / Logsign support directly to obtain an authoritative statement on whether 6.4.117 remediates CWE-1392, and request the associated advisory or release notes. Given patch confidence 0/4, no independent confirmation exists.
• If a fixed release is confirmed, stage the upgrade in a non-production environment, validate log ingestion and integrations, then upgrade production instances during a maintenance window.
• After upgrade, verify that default accounts are removed or force a password change, since an upgrade alone does not necessarily invalidate previously set credentials.

3) Long-term hardening:

• Adopt a policy that no product may be deployed with vendor-default credentials; enforce a credential provisioning step in the deployment runbook with sign-off before production exposure.
• Integrate the SIEM's own authentication logs into an independent, tamper-resistant logging pipeline so that compromise of the SIEM does not destroy the evidence of that compromise.
• Rotate all integration and API credentials held by the SIEM as part of the remediation, since an attacker with console access could have exfiltrated them.
• Implement continuous asset discovery to detect newly deployed or forgotten SIEM instances, which are common sources of default-credential exposure.
• Apply least-privilege principles to SIEM accounts and separate read-only analyst accounts from administrative accounts.

References

1. NVD — CVE-2026-90924: https://nvd.nist.gov/vuln/detail/CVE-2026-90924
2. MITRE CWE-1392 — Use of Default Credentials: https://cwe.mitre.org/data/definitions/1392.html
3. MITRE ATT&CK T1078.001 — Valid Accounts: Default Accounts: https://attack.mitre.org/techniques/T1078/001/
4. Innotim Software / Logsign — vendor product information and support portal (consult directly for advisory status; no advisory located in tracked sources).
5. CISA Known Exploited Vulnerabilities Catalog (CVE-2026-90924 not listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No threat actor campaigns or exploit-in-the-wild evidence are associated with this CVE in the provided data.