Total
1485 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-92256 | 2026-09-15 | N/A | 6.5 MEDIUM | ||
| NR255-V version 1.5.130703 contains a sensitive information disclosure vulnerability in l2tpd_config_show_cgi.c, ipsec_show_cgi.c, and mod_vpn_remote/plan.json read handlers. Attackers can query l2tpd_config_show.cgi to expose stored IPsec PSK and RSA key material. | |||||
| CVE-2026-76871 | 2026-09-15 | N/A | 6.5 MEDIUM | ||
| Netcore NR255-V version 1.5.130703 contains a sensitive information disclosure vulnerability in mod_vpn_remote/plan.json, pptpd_user_show.cgi, pptp_client_config_show.cgi, and l2tpd_user_show.cgi. Attackers can leverage these components to obtain PPTP and L2TP VPN credentials. | |||||
| CVE-2026-76859 | 2026-09-15 | N/A | 6.5 MEDIUM | ||
| Netcore NR255-V version 1.5.130703 contains a sensitive information disclosure vulnerability in the user_pass_show.cgi component. Low-privilege attackers can exploit this flaw via ui_config_2.xml and misc.js to disclose router credentials. | |||||
| CVE-2026-76857 | 2026-09-15 | N/A | 6.5 MEDIUM | ||
| Netcore NR255-V firmware version 1.5.130703 contains a sensitive information disclosure vulnerability in the ddns_wan_list_show.cgi endpoint and related DDNSset_cgi, IGD_GetCgiHandler, and IGD_CgiCall components. Attackers who reach this CGI handler can obtain plaintext DDNS credentials, exposing sensitive account information. | |||||
| CVE-2026-76854 | 2026-09-15 | N/A | 6.5 MEDIUM | ||
| Netcore NR255-V version 1.5.130703 contains a sensitive information disclosure vulnerability in l7_web_auth_user_show.cgi related to captive-portal credential handling. Attackers can query this component to obtain captive-portal user credentials, compromising confidentiality of authenticated network access. | |||||
| CVE-2026-61802 | 1 Wazuh | 1 Wazuh | 2026-09-15 | N/A | 6.5 MEDIUM |
| Wazuh is an open-source security platform providing unified XDR and SIEM protection for endpoints and cloud workloads. In versions 4.14.0 through 4.14.6, a low-privilege API user can read the cleartext cluster key from a configuration endpoint that fails to redact it. The REST API provides a masking control, mask_sensitive_config, that redacts sensitive fields such as authd.pass and cluster.key from configuration responses for users who lack update-config permission, and every config-read endpoint carries this decorator except GET /cluster/local/config. That endpoint, backed by read_config_wrapper, is gated only by cluster:read and returns the local node's cluster configuration including the cleartext key, whereas its siblings return the same value masked. As a result, any account with the default readonly or cluster_readonly role, which is explicitly denied update-config precisely so it cannot view secrets, receives the real cluster key. Because the cluster key authenticates and encrypts traffic between cluster nodes, disclosing it to an unprivileged account provides the authentication precondition for the cluster-peer remote code execution chains established by prior advisories. This issue is fixed in version 4.14. | |||||
| CVE-2026-11921 | 2026-09-15 | N/A | N/A | ||
| IBM Verify Identity Access containers may not apply management password change operations correctly. | |||||
| CVE-2026-91982 | 2026-09-15 | N/A | 4.3 MEDIUM | ||
| Vikunja before 2.6.0 continues to expose the raw TOTP shared secret after enrollment through the GET /api/v1/user/settings/totp and /api/v1/user/settings/totp/qrcode endpoints without re-authentication. Attackers with a valid access token can read the secret, import it into their own authenticator, and generate valid codes indefinitely to defeat the second factor and enable account takeover. | |||||
| CVE-2026-81381 | 1 Microsoft | 1 Visual Studio Code | 2026-09-15 | N/A | 6.5 MEDIUM |
| Insufficiently protected credentials in GitHub Copilot and Visual Studio Code allows an unauthorized attacker to disclose information over a network. | |||||
| CVE-2026-9079 | 1 Haxx | 1 Curl | 2026-09-15 | N/A | 9.8 CRITICAL |
| libcurl had a flaw that when instructed to clear proxy authentication credentials which made it not do so, leaving the old credentials around to get used for subsequent transfers that should not know nor use them. | |||||
| CVE-2026-8926 | 1 Haxx | 1 Curl | 2026-09-15 | N/A | 9.1 CRITICAL |
| When asking curl to use a `.netrc` file to find credentials and at the same time specifying a URL with a username (without a password), like `https://user@example.com/`, curl could wrongly get and use the password for *another* user set in the `.netrc` file for that host if such a one exists and there is no match for the specified user. | |||||
| CVE-2026-6253 | 1 Haxx | 1 Curl | 2026-09-15 | N/A | 5.9 MEDIUM |
| curl might erroneously pass on credentials for a first proxy to a second proxy. This can happen when the following conditions are true: 1. curl is setup to use specific different proxies for different URL schemes 2. the first proxy needs credentials 3. the second proxy uses no credentials 4. while using the first proxy (using say `http://`), curl is asked to follow a redirect to a URL using another scheme (say `https://`), accessed using a second, different, proxy | |||||
| CVE-2026-3783 | 1 Haxx | 1 Curl | 2026-09-15 | N/A | 5.3 MEDIUM |
| When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one. | |||||
| CVE-2025-14524 | 1 Haxx | 1 Curl | 2026-09-15 | N/A | 5.3 MEDIUM |
| When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a cross-protocol redirect to a second URL that uses an IMAP, LDAP, POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the new target host. | |||||
| CVE-2026-84179 | 2026-09-14 | N/A | 6.5 MEDIUM | ||
| Description getTopologyPageInfo merged the Nimbus daemon configuration with the topology's own configuration and returned the result without redaction in the topology_conf field of TopologyPageInfo. The Storm UI copied that value verbatim into the configuration field of GET /api/v1/topology/{id} and of the corresponding metrics endpoint. Where the cluster is configured with them, the merged map includes storm.zookeeper.auth.payload, which Storm's own documentation directs operators to keep in storm-cluster-auth.yaml under permissions that deny access from workers, together with the keystore and truststore passwords for the Thrift, Netty and ZooKeeper TLS configuration, and any plugin key whose name denotes a secret. getTopologyPageInfo is a topology read-only operation. Under SimpleACLAuthorizer a principal listed in topology.readonly.users or topology.readonly.groups could therefore read daemon credentials that the dedicated cluster configuration API, getNimbusConf, redacts and that is gated on nimbus.users instead. The sibling operations that exist to serve configuration were masked; the topology page, which merges in strictly more daemon state, was not. Mitigation Upgrade to 3.1.0, where credential-bearing values are masked before any configuration is served over the Nimbus API. Users who cannot upgrade immediately should remove any principal that is not trusted with cluster credentials from topology.readonly.users, topology.readonly.groups, topology.users and topology.groups, and should rotate the ZooKeeper authentication payload and any TLS keystore or truststore passwords that were reachable through the topology page. Credit Wanxin Yin (yaklang.io) reported this issue to the Apache Security Team. | |||||
| CVE-2026-75015 | 2026-09-14 | N/A | 4.9 MEDIUM | ||
| Insufficiently Protected Credentials vulnerability in Apache Syncope. Audit events, when sent to the configured store, are not sufficiently masked for the sensitive values they might carry on their payloads, thus allowing administrators to access such sensitive values. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. | |||||
| CVE-2026-82433 | 2026-09-14 | N/A | 6.5 MEDIUM | ||
| Description `getNimbusConf` returned the complete daemon configuration without redaction after only a user-level authorization check. Where the cluster is configured with them, that response includes `storm.zookeeper.auth.payload` and the keystore and truststore passwords for the Thrift, Netty and ZooKeeper TLS configuration. The project masks passwords elsewhere before display, so the omission here is inconsistent rather than intended. The UI endpoint `/api/v1/cluster/configuration` compounded this. It carried no `@AuthNimbusOp` annotation, and the authorization filter treated a missing annotation as "no gate required" and returned immediately, so the endpoint applied no per-user check at all and proxied the request under the UI daemon's own principal. Any user able to pass `ui.filter` therefore received the full configuration, including principals that Nimbus itself would have refused. Mitigation Upgrade to 3.1.0, where credential-bearing values are masked before the configuration is served and where every UI API endpoint must declare its authorization explicitly. Users who cannot upgrade immediately should place the UI behind an authenticating reverse proxy that restricts `/api/v1/cluster/configuration`, and should rotate the ZooKeeper authentication payload and any TLS keystore or truststore passwords that were reachable through it. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. | |||||
| CVE-2026-82434 | 2026-09-14 | N/A | 6.5 MEDIUM | ||
| Description When ZooKeeper authentication is configured, Storm deliberately retains `storm.zookeeper.topology.auth.payload` in the topology configuration, because workers need it. Nimbus then served that configuration verbatim to any caller holding read-only topology permissions, so a user whose only grant was the ability to view a topology received its ZooKeeper credential. That credential is not read-only. The cluster state implementation uses write-capable ACLs for worker heartbeats, backpressure and error state, so a recipient can forge or remove that state for the topology concerned. It is not a write credential on assignments. The same advisory covers the submission client, which logged the generated payload at INFO on every submission that generated one, and the SASL handlers, which logged it at DEBUG. The credential therefore also reached any log aggregation or support bundle collected from the cluster. Mitigation Upgrade to 3.1.0, where the payload is removed from the configuration served to read-only callers and is no longer written to logs. Users who cannot upgrade immediately should rotate `storm.zookeeper.topology.auth.payload` for existing topologies, review retained logs and support bundles for the value, and restrict read-only topology permissions to trusted principals. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. | |||||
| CVE-2026-82786 | 2026-09-14 | N/A | 6.3 MEDIUM | ||
| Insufficiently protected credentials issue exists in Remote I/O Coupler Unit (Server Type) CPSN-MCB271-*. If this vulnerability is exploited, sensitive information may be restored from a backup file. | |||||
| CVE-2026-90895 | 2026-09-14 | N/A | N/A | ||
| Affected versions of MISP’s interactive CLI shell implement access control independently from the normal web application, causing several authorization inconsistencies. The patch shows that CLI access could differ from the web application in multiple security-sensitive areas: - feed listings did not enforce the same lookup_visible restrictions for non-host-organisation users; - feed detail access did not enforce the same host-organisation/site-admin authorization as FeedsController::view(); - Feed.headers, which can contain HTTP authorization credentials, could be exposed instead of being hidden or masked; - server synchronization authkey values were not explicitly hidden from CLI detail output; - sharing-group detail access did not consistently use SharingGroup::checkIfAuthorised(); - the use command could establish context for a record without first proving that the user was authorized to view that record The commit additionally hardens pagination and terminal rendering, including neutralization of terminal control sequences found in database-backed values. Those are important hardening changes, but the main vulnerability is the CLI authorization/data-disclosure mismatch. Version affected: ≤2.5.45 | |||||