| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Improper handling of physical conditions in the bike-shutdown control of the Indian Motorcycle Scout Bobber + Tech 2025 model year allows a physical attacker with access to the Wireless Control Module (WCM) wiring harness to bypass the anti-theft shutdown. The WCM signals shutdown to a peer ECU via a falling-edge voltage transition on a dedicated wire pair. The receiving ECU does not distinguish between an active shutdown pulse and an open-circuit / disconnected condition; interrupting the relevant wires leaves the motorcycle fully operable even though the WCM never validated the rider's PIN. Specific connector details have been withheld pending vendor remediation. |
| Expected behavior violation in the in-vehicle network of the Indian Motorcycle Scout Bobber + Tech 2025 model year allows an adjacent-network attacker to bypass the motorcycle's anti-theft shutdown by forcing the Wireless Control Module (WCM) into the CAN bus-off state. Using a well-known CAN error-frame injection technique against a periodic WCM transmission, the attacker drives the WCM CAN controller's transmit error counter past the bus-off threshold, after which the WCM stops transmitting all messages, including the shutdown command. Peer ECUs do not interpret WCM silence as a security event and continue normal operation, allowing the motorcycle to be operated despite the immobilizer never having been unlocked. Specific protocol details have been withheld pending vendor remediation. |
| Incorrect behavior order in the Infotainment / Digital Round display of the Indian Motorcycle Scout Bobber + Tech 2025 model year allows an adjacent-network attacker to bypass the PIN entry screen. The Infotainment uses presence of Wireless Control Module (WCM) traffic during its boot window as a proxy for whether an immobilizer is fitted; if no WCM messages are observed, it skips the PIN entry screen and shows the normal user interface. An attacker who silences the WCM during the boot window — for example via a separately tracked CAN bus-off technique — can present a fully unlocked Infotainment despite the PIN never being entered. Specific timing and protocol details have been withheld pending vendor remediation. |
| Incorrect behavior order in the Infotainment / Digital Round display of the Indian Motorcycle Scout Bobber + Tech 2025 model year allows an adjacent-network attacker to bypass the PIN entry screen. The Infotainment uses presence of Wireless Control Module (WCM) traffic during its boot window as a proxy for whether an immobilizer is fitted; if no WCM messages are observed, it skips the PIN entry screen and shows the normal user interface. An attacker who silences the WCM during the boot window — for example via a separately tracked CAN bus-off technique — can present a fully unlocked Infotainment despite the PIN never being entered. Specific timing and protocol details have been withheld pending vendor remediation. |
| A CWE-754: Improper Check for Unusual or Exceptional Conditions vulnerability exists in Modicon M580, Modicon M340, Modicon Quantum, Modicon Premium (see security notification for specific versions) which could cause a Denial of Service of the controller when reading specific memory blocks using Modbus TCP. |
| A CWE-754: Improper Check for Unusual or Exceptional Conditions vulnerability exists in Modicon M580, Modicon M340, Modicon Quantum, Modicon Premium (see security notification for specific versions) which could cause a Denial of Service when writing specific physical memory blocks using Modbus TCP. |
| A CWE-248: Uncaught Exception vulnerability exists in Modicon M580 (firmware version prior to V2.90) and Modicon M340 (firmware version prior to V3.10), which could cause a possible denial of service when writing to specific memory addresses in the controller over Modbus. |
| A CWE-754: Improper Check for Unusual or Exceptional Conditions vulnerability exists which could cause a possible Denial of Service when specific Modbus frames are sent to the controller in the products: Modicon M340 - firmware versions prior to V3.01, Modicon M580 - firmware versions prior to V2.80, All firmware versions of Modicon Quantum and Modicon Premium. |
| A CWE-248: Uncaught Exception vulnerability exists in all versions of the Modicon M580, Modicon M340, Modicon Quantum, and Modicon Premium which could cause denial of service when an invalid private command parameter is sent to the controller over Modbus. |
| A CWE-754: Improper Check for Unusual or Exceptional Conditions vulnerability exists in Modicon M580, Modicon M340, Modicon Quantum, Modicon Premium (see security notification for specific versions) which could cause a Denial of Service when reading data with invalid index using Modbus TCP. |
| An Improper Check for Unusual or Exceptional Conditions vulnerability exists in Schneider Electric's Modicon M221 product (all references, all versions prior to firmware V1.6.2.0). The vulnerability allows unauthorized users to remotely reboot Modicon M221 using crafted programing protocol frames. |
| A CWE-754: Improper Check for Unusual or Exceptional Conditions vulnerability exists in the Web Server on Modicon M340, Legacy Offers Modicon Quantum and Modicon Premium and associated Communication Modules (see security notification for affected versions), that could cause denial of HTTP and FTP services when a series of specially crafted requests is sent to the controller over HTTP. |
| A CWE-754: Improper Check for Unusual or Exceptional Conditions vulnerability exists in Quantum Ethernet Network module 140NOE771x1 (Versions 7.0 and prior), Quantum processors with integrated Ethernet – 140CPU65xxxxx (all Versions), and Premium processors with integrated Ethernet (all Versions), which could cause a Denial of Service when sending a specially crafted command over Modbus. |
| free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's PCF POST /npcf-smpolicycontrol/v1/sm-policies handler (HandleCreateSmPolicyRequest) panics with a nil-pointer dereference when a downstream OpenAPI consumer call (UDR lookup) returns 404 Not Found and the consumer wrapper returns err != nil together with a nil response struct. The handler logs the OpenAPI error and continues executing instead of returning, then dereferences the nil response struct on a subsequent line and panics. Gin recovery converts the panic into HTTP 500, so a single attacker-shaped POST returns 500 instead of a clean 4xx whenever the downstream lookup fails. The PCF process keeps running. The trigger is a single POST containing input that causes the downstream UDR lookup to fail (e.g. an unknown DNN). In 4.2.1 this endpoint is also reachable WITHOUT an Authorization header because the PCF Npcf_SMPolicyControl route group is mounted without inbound auth middleware. This vulnerability is fixed in 4.2.2. |
| free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's PCF POST /npcf-policyauthorization/v1/app-sessions handler panics on a single authenticated request whose ascReqData.suppFeat == "1" (enabling traffic-routing feature negotiation) and whose medComponents entries supply an afAppId but NO AfRoutReq. The create path then calls provisioningOfTrafficRoutingInfo(smPolicy, appID, routeReq, ...) with routeReq == nil and dereferences routeReq.RouteToLocs (and other fields) without a nil check, causing runtime error: invalid memory address or nil pointer dereference. Gin recovery converts the panic into HTTP 500. This vulnerability is fixed in 4.2.2. |
| The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which makes it easier for man-in-the-middle attackers to obtain cleartext data via a padding-oracle attack, aka the "POODLE" issue. |
| free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's NEF terminates the entire process when a stored PFD-subscription notifyUri cannot be reached. In PfdChangeNotifier.FlushNotifications(), the notifier calls NnefPFDmanagementNotify(...) and on any delivery error invokes logger.PFDManageLog.Fatal(err), which is os.Exit(1)-equivalent in Go. An attacker who can create a PFD subscription with an attacker-chosen notifyUri and then trigger a PFD change can deterministically kill NEF on the asynchronous delivery attempt -- the process exits with status 1, dropping NEF's entire SBI surface until restart. This vulnerability is fixed in 4.2.2. |
| free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's NEF PATCH /3gpp-pfd-management/v1/{afId}/transactions/{transId}/applications/{appId} handler panics with a nil-pointer dereference when the upstream UDR call fails AND the consumer wrapper returns err != nil together with a nil *ProblemDetails. The handler's errPfdData != nil branch builds its own problemDetailsErr correctly, but immediately after it reads problemDetails.Cause (the OTHER value, which is nil in this branch) and panics. Gin recovery converts the panic into HTTP 500, so a single PATCH against this endpoint returns 500 instead of the intended controlled error response whenever UDR access is failing. This vulnerability is fixed in 4.2.2. |
| free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's UDR nudr-dr DELETE /subscription-data/{ueId}/{servingPlmnId}/ee-subscriptions/{subsId}/amf-subscriptions handler panics on a single authenticated request against a fresh UDR instance when the supplied ueId does not exist in UESubsCollection. The processor checks value, ok := udrSelf.UESubsCollection.Load(ueId) and sets a 404 USER_NOT_FOUND problem-details on the miss path, but execution continues and immediately runs value.(*udr_context.UESubsData) -- a Go type assertion on a nil interface, which panics with interface conversion: interface {} is nil, not *context.UESubsData. Gin recovery converts the panic into HTTP 500, but the endpoint remains repeatedly panicable. This vulnerability is fixed in 4.2.2. |
| free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's NRF root SBI endpoint POST /oauth2/token contains a parser-level type-confusion bug family. The handler in NFs/nrf/internal/sbi/api_accesstoken.go reflects over models.NrfAccessTokenAccessTokenReq, special-cases only plain string and NrfNfManagementNfType fields, and treats every other field as if it were a single models.PlmnId. The parsed *models.PlmnId is then assigned with reflect.Value.Set() to whichever field name the attacker put in the form body, which panics whenever the destination field's real type is incompatible (slice, different struct, primitive). Gin recovery converts each panic into HTTP 500, but the endpoint remains remotely panicable from a single unauthenticated form-encoded request and is repeatedly triggerable. This vulnerability is fixed in 4.2.2. |
