CVE-2026-23362 is a reminder that some of the most consequential Linux kernel fixes are not dramatic remote-code-execution stories, but precise corrections in synchronization code that protect specialized systems from crashing at the worst possible moment. The flaw affects the Linux kernel’s CAN Broadcast Manager path, where a missing spinlock initialization can be reached when receive-side CAN logic sends a predefined response to a Remote Transmission Request frame. NVD rates the issue CVSS 3.1: 5.5 Medium, with the impact focused on availability, not confidentiality or data theft. For WindowsForum readers, the interesting part is not only the Linux patch itself, but the growing overlap between Windows, WSL, Azure, embedded Linux, automotive tooling, and mixed operating system fleets.
The Linux kernel’s Controller Area Network subsystem exists for a world very different from the ordinary Ethernet and Wi-Fi stack most PC users think about. CAN is a compact, resilient bus protocol widely associated with vehicles, industrial equipment, robotics, medical devices, and embedded controllers. It was designed for short, deterministic messages between devices that need to coordinate reliably under electrical noise and tight timing constraints.
Within Linux, SocketCAN exposes CAN communication through a familiar socket interface. That design made CAN programming more approachable because developers could use networking patterns rather than treating every CAN controller as a one-off device. Over time, Linux became an important platform for diagnostics, gateways, test rigs, prototyping systems, fleet hardware, and industrial controllers that bridge CAN traffic into higher-level applications.
The vulnerable component in this case is the Broadcast Manager, commonly referred to as BCM. It supports scheduled transmissions, receive filters, and higher-level CAN message handling so applications do not need to implement every timing loop themselves in user space. That convenience matters in embedded environments, where CPU budget, timing, and reliability are often more important than raw throughput.
CVE-2026-23362 was published by NVD on March 25, 2026, and NVD’s analysis was updated on April 24, 2026. The weakness is classified as CWE-667: Improper Locking, and the recorded CVSS vector is local, low-complexity, low-privilege, no-user-interaction, unchanged-scope, with high availability impact. In plain English, the likely failure mode is kernel instability or denial of service rather than remote compromise.
The earlier commit identified as
That means a receive-side operation can behave like a transmit operation under specific conditions. If
Key facts make the bug easier to understand:
A kernel crash on a developer workstation is annoying. A kernel crash on an industrial gateway, vehicle test bench, manufacturing controller, robotics hub, or diagnostic appliance can interrupt operations and obscure the true root cause. Availability bugs become operational incidents when the system sits in a production path.
The availability impact is marked high because the consequence can be a system-level failure. In kernel terms, a denial of service is not just one app crashing. It may mean the entire node becomes unreliable until rebooted, logs are reviewed, and workloads are restored.
For risk teams, the practical question is not “Is this critical?” but “Can an untrusted or weakly isolated workload reach CAN BCM on a system we depend on?” That question is more useful than a generic severity label.
The original CVE was received from kernel.org on March 25, 2026. Additional references were added by kernel.org on April 18, and NVD added CVSS, CWE, and CPE enrichment on April 24. This staged timeline is typical for kernel CVEs, where the patch, stable backports, distribution triage, and vulnerability database enrichment often arrive in waves.
The important operational move is to check your vendor’s kernel package, not just
Practical inventory checks should include:
WSL 2 uses a real Linux kernel delivered on a separate update track from the Windows image. Microsoft’s documentation describes the WSL 2 kernel as open source, distributed through Microsoft Update, and maintained separately from the Windows Subsystem for Linux user-mode components. That separation matters because a Windows cumulative update and a WSL kernel update are related, but not the same artifact.
Azure is another story. Cloud VMs generally do not expose physical CAN buses, but Linux kernel CVEs still flow through cloud image maintenance, appliance vendors, and specialized workloads. If a vendor runs CAN-related software inside a Linux VM or edge product managed from Windows tools, the patching responsibility remains real.
For Windows-heavy teams, the key takeaway is simple: Linux kernel risk is now part of Windows operations. If your Windows admins also own WSL, Hyper-V Linux guests, Azure Linux systems, IoT gateways, or build pipelines for embedded devices, they need visibility into kernel advisories like this one.
The vulnerable case involves the receive setup path combined with RTR handling. RTR frames are less fashionable in some modern CAN deployments than ordinary data frames, but they remain part of the protocol and may appear in legacy systems, diagnostic workflows, or specialized equipment. Old protocol features do not disappear just because newer architectures prefer different patterns.
Potentially relevant environments include:
The second step is to determine who can create CAN BCM sockets or influence services that do. Local privilege requirements still matter, but “local” can include containerized applications, vendor daemons, remote job runners, and compromised developer accounts. Local-only does not mean harmless when the local boundary is porous.
If immediate patching is not available, teams can reduce risk by removing unnecessary CAN BCM access. Disabling the module may be reasonable for general-purpose systems that never use CAN. It may not be acceptable on industrial equipment where CAN communication is mission-critical.
A financial services Linux server with no CAN support loaded may be patched on the standard kernel cycle. A manufacturing gateway coordinating production equipment may need a maintenance window sooner, even if the CVSS score is identical. That distinction is why asset labels matter.
Useful enterprise questions include:
Developers are a different audience. Embedded developers, automotive researchers, makers working with vehicle diagnostics, and Windows users combining WSL with Linux tooling may have exactly the kind of experimental setups where local boundaries are loose. A lab workstation with sudo access, USB CAN hardware, and multiple test scripts can become an unusually rich environment for triggering kernel edge cases.
Recommended developer actions include:
For Microsoft, the lesson is also strategic. The company ships, supports, and depends on Linux in WSL, Azure, containers, network appliances, and internal infrastructure. A Linux kernel advisory is no longer a competitor’s problem; it is part of the platform reality surrounding Windows.
This vulnerability also highlights a competitive advantage for platforms with strong update channels. Systems that can rapidly consume stable kernel fixes are less exposed to lingering medium-severity bugs. Systems frozen on vendor board-support packages may carry small kernel flaws for years.
That pattern is common in mature kernels. Features accrete over decades, and a subsystem that looks linear on a whiteboard may contain legacy behavior, callbacks, timers, filters, and exceptional paths. Security bugs often live in the gap between the mental model and the actual call graph.
The case also reinforces the value of fuzzing and automated bug discovery. The patch trail references syzbot reporting, which is exactly the kind of toolchain that finds strange combinations humans may not prioritize. Kernel security increasingly depends on this constant adversarial testing of edge paths.
Engineering takeaways include:
Security teams should also watch whether scanners update detection logic beyond broad CPE matching. The best vulnerability management tools will help distinguish systems where CAN BCM is present and reachable from systems where the vulnerable code is dormant. That distinction matters for prioritization and maintenance planning.
Important follow-up items include:
Source: NVD / Linux Kernel Security Update Guide - Microsoft Security Response Center
Background
The Linux kernel’s Controller Area Network subsystem exists for a world very different from the ordinary Ethernet and Wi-Fi stack most PC users think about. CAN is a compact, resilient bus protocol widely associated with vehicles, industrial equipment, robotics, medical devices, and embedded controllers. It was designed for short, deterministic messages between devices that need to coordinate reliably under electrical noise and tight timing constraints.Within Linux, SocketCAN exposes CAN communication through a familiar socket interface. That design made CAN programming more approachable because developers could use networking patterns rather than treating every CAN controller as a one-off device. Over time, Linux became an important platform for diagnostics, gateways, test rigs, prototyping systems, fleet hardware, and industrial controllers that bridge CAN traffic into higher-level applications.
The vulnerable component in this case is the Broadcast Manager, commonly referred to as BCM. It supports scheduled transmissions, receive filters, and higher-level CAN message handling so applications do not need to implement every timing loop themselves in user space. That convenience matters in embedded environments, where CPU budget, timing, and reliability are often more important than raw throughput.
CVE-2026-23362 was published by NVD on March 25, 2026, and NVD’s analysis was updated on April 24, 2026. The weakness is classified as CWE-667: Improper Locking, and the recorded CVSS vector is local, low-complexity, low-privilege, no-user-interaction, unchanged-scope, with high availability impact. In plain English, the likely failure mode is kernel instability or denial of service rather than remote compromise.
What CVE-2026-23362 Actually Fixes
The technical change behind CVE-2026-23362 is almost comically small: add a missingspin_lock_init() when allocating a receive-side BCM operation in bcm_rx_setup(). Yet kernel security is full of such cases, where one missing initialization line can separate stable synchronization from undefined behavior. The fix matters because the receive path is not always purely receive-only.The earlier commit identified as
c2aba69d0c36 added locking for runtime updates to a sending bcm_op. That was sensible because TX_SETUP can update variables while an existing CAN transmission operation is alive. The problem was that the related lock was initialized in the transmit setup path, while one receive-side exception could still enter transmit code.The RTR Exception
The exception is RX_RTR_FRAME. In CAN, an RTR frame asks another node to transmit a data frame with a particular identifier. When the Broadcast Manager is configured to respond to such a request, an RX operation can triggerbcm_can_tx() and therefore touch transmit-side locking.That means a receive-side operation can behave like a transmit operation under specific conditions. If
bcm_tx_lock is not initialized for that receive-side structure, the kernel may attempt to use an invalid or uninitialized spinlock. That can lead to lock warnings, crashes, hangs, or other unstable behavior depending on timing and memory state.Key facts make the bug easier to understand:
- Affected subsystem: Linux kernel CAN BCM.
- Fault class: Improper locking through missing spinlock initialization.
- Trigger path: Receive setup using RX_RTR_FRAME that causes a transmit response.
- Security impact: Primarily availability loss through kernel instability.
- Exploit position: Local attacker or local process with relevant CAN socket access.
- Fix shape: Initialize
bcm_tx_lockinside the receive setup allocation path.
Why a Medium-Rated Kernel Bug Still Matters
A Medium CVSS score can lull teams into underreacting, especially when dashboards are crowded with critical browser, identity, and remote-access vulnerabilities. CVE-2026-23362 is not the kind of flaw that should cause panic across every desktop estate. But in the environments where CAN matters, availability is not a secondary concern.A kernel crash on a developer workstation is annoying. A kernel crash on an industrial gateway, vehicle test bench, manufacturing controller, robotics hub, or diagnostic appliance can interrupt operations and obscure the true root cause. Availability bugs become operational incidents when the system sits in a production path.
CVSS Does Not Tell the Whole Story
NVD’s vector says the flaw requires local access and low privileges, with no user interaction. That makes the vulnerability less exposed than a remote network service bug. However, many CAN-enabled systems run custom applications, automation scripts, containers, or vendor services with enough local access to open sockets and interact with device interfaces.The availability impact is marked high because the consequence can be a system-level failure. In kernel terms, a denial of service is not just one app crashing. It may mean the entire node becomes unreliable until rebooted, logs are reviewed, and workloads are restored.
For risk teams, the practical question is not “Is this critical?” but “Can an untrusted or weakly isolated workload reach CAN BCM on a system we depend on?” That question is more useful than a generic severity label.
Affected Kernel Ranges and Patch Timing
NVD’s affected software configuration list spans multiple Linux kernel branches, including stable and release-candidate lines. The listed vulnerable ranges include portions of 5.4, 5.10, 5.15, 6.1, 6.6, 6.12, 6.14, 6.15, 6.18, 6.19, and 7.0 release candidates. That broad spread reflects how kernel fixes are backported across many maintained trees, not necessarily that every system has CAN enabled or reachable.The original CVE was received from kernel.org on March 25, 2026. Additional references were added by kernel.org on April 18, and NVD added CVSS, CWE, and CPE enrichment on April 24. This staged timeline is typical for kernel CVEs, where the patch, stable backports, distribution triage, and vulnerability database enrichment often arrive in waves.
Distribution Status Is the Deciding Factor
Administrators should avoid making decisions solely from upstream version numbers. Enterprise distributions routinely backport fixes without changing to a newer headline kernel. Ubuntu, for example, tracked the issue as Medium and showed vulnerable status for several supported release/kernel combinations while marking others as not affected or not in release.The important operational move is to check your vendor’s kernel package, not just
uname -r. A kernel version string may include vendor patches that already contain the one-line fix. Conversely, a seemingly modern custom kernel may still be missing the relevant backport.Practical inventory checks should include:
- Kernel package source from the distribution or appliance vendor.
- Loaded module state for
can_bcmand related CAN components. - CAN hardware or virtual CAN usage on the host.
- Container access to host networking and device interfaces.
- Vendor advisories for embedded products that ship fixed kernels later than upstream.
- Custom kernel builds maintained by internal engineering teams.
The Windows Angle: WSL, Azure, and Mixed Fleets
At first glance, a Linux CAN BCM flaw may seem outside the WindowsForum universe. That view is increasingly outdated. Windows users now commonly run Linux workloads through WSL 2, enterprises operate Linux at scale in Azure, and Windows-based engineering teams often use Linux tooling to interact with embedded boards, USB adapters, and vehicle networks.WSL 2 uses a real Linux kernel delivered on a separate update track from the Windows image. Microsoft’s documentation describes the WSL 2 kernel as open source, distributed through Microsoft Update, and maintained separately from the Windows Subsystem for Linux user-mode components. That separation matters because a Windows cumulative update and a WSL kernel update are related, but not the same artifact.
Exposure Is Contextual, Not Automatic
For ordinary WSL users running Ubuntu for compilers, Python, Node.js, containers, or shell utilities, CVE-2026-23362 is unlikely to be a headline risk. WSL environments usually do not sit on raw CAN buses in the way an embedded Linux gateway or vehicle test system does. Still, developers who attach USB CAN adapters, build custom WSL kernels, or bridge specialized hardware into Linux environments should pay closer attention.Azure is another story. Cloud VMs generally do not expose physical CAN buses, but Linux kernel CVEs still flow through cloud image maintenance, appliance vendors, and specialized workloads. If a vendor runs CAN-related software inside a Linux VM or edge product managed from Windows tools, the patching responsibility remains real.
For Windows-heavy teams, the key takeaway is simple: Linux kernel risk is now part of Windows operations. If your Windows admins also own WSL, Hyper-V Linux guests, Azure Linux systems, IoT gateways, or build pipelines for embedded devices, they need visibility into kernel advisories like this one.
CAN BCM in the Real World
The CAN Broadcast Manager exists to simplify repeated and filtered CAN communication. Instead of writing user-space loops for every timed send or receive filter, applications can hand work to the kernel. That is efficient, but it also means subtle kernel bugs can appear only when specific message modes and flags interact.The vulnerable case involves the receive setup path combined with RTR handling. RTR frames are less fashionable in some modern CAN deployments than ordinary data frames, but they remain part of the protocol and may appear in legacy systems, diagnostic workflows, or specialized equipment. Old protocol features do not disappear just because newer architectures prefer different patterns.
Where the Attack Surface Appears
The direct attack surface is local because a process needs to interact with CAN sockets and configure the relevant BCM operation. In a tightly controlled embedded image, only trusted services may have that ability. In a more open engineering workstation or test server, developers, scripts, containers, and automation agents may have broader access than expected.Potentially relevant environments include:
- Automotive diagnostics using SocketCAN and USB CAN interfaces.
- Industrial gateways bridging CAN, Ethernet, and cloud telemetry.
- Robotics systems using CAN for motor controllers and sensors.
- Laboratory rigs where multiple users run experimental CAN tooling.
- CI systems that test embedded software against virtual CAN devices.
- Fleet maintenance platforms running Linux-based data collectors.
How Administrators Should Triage It
The first triage step is to determine whether the system uses CAN at all. Many Linux servers compile or package CAN support but never load the relevant modules. A web server with no CAN device, no virtual CAN configuration, and nocan_bcm usage is in a very different position from a factory gateway.The second step is to determine who can create CAN BCM sockets or influence services that do. Local privilege requirements still matter, but “local” can include containerized applications, vendor daemons, remote job runners, and compromised developer accounts. Local-only does not mean harmless when the local boundary is porous.
A Practical Triage Checklist
Administrators can use a straightforward sequence before deciding urgency. The goal is not to overcomplicate a medium-severity issue, but to separate theoretical exposure from real operational risk.- Identify systems running Linux kernels in the affected ranges or vendor advisories.
- Check whether CAN modules such as
can,can_raw,can_bcm, or CAN device drivers are loaded. - Review whether virtual CAN interfaces are used in testing or CI.
- Confirm whether untrusted users, containers, or applications can open CAN sockets.
- Apply vendor kernel updates where available, then reboot if live patching does not cover the fix.
- If patching is delayed, disable or blacklist unused CAN BCM functionality where safe.
- Monitor kernel logs for BCM, spinlock, lockdep, oops, panic, or watchdog messages.
Mitigation and Hardening Options
The primary mitigation is simple: apply a kernel update that includes the fix. Because the patch initializesbcm_tx_lock in bcm_rx_setup(), remediation is best handled through official kernel packages or vendor firmware updates. Custom cherry-picking is possible for engineering teams, but production systems should follow supported update channels wherever possible.If immediate patching is not available, teams can reduce risk by removing unnecessary CAN BCM access. Disabling the module may be reasonable for general-purpose systems that never use CAN. It may not be acceptable on industrial equipment where CAN communication is mission-critical.
Temporary Controls
Temporary controls should be treated as risk reducers, not permanent fixes. The most robust answer remains a patched kernel.- Disable
can_bcmif the host has no legitimate CAN Broadcast Manager use. - Restrict local shell access on CAN-enabled gateways and test rigs.
- Limit container privileges that expose host networking or device interfaces.
- Avoid RX_RTR_FRAME configurations in internal tools until patched.
- Segment engineering workstations from production CAN-connected systems.
- Enable stronger logging for kernel warnings on development and test nodes.
- Review USB device forwarding workflows for CAN adapters on Windows and Linux hosts.
Enterprise Impact
In enterprise environments, CVE-2026-23362 is mainly an asset classification problem. The flaw will appear in scanners as a Linux kernel CVE, but the scanner may not know whether a host has any CAN exposure. Security teams need context from operations, engineering, and platform owners to assign the right remediation priority.A financial services Linux server with no CAN support loaded may be patched on the standard kernel cycle. A manufacturing gateway coordinating production equipment may need a maintenance window sooner, even if the CVSS score is identical. That distinction is why asset labels matter.
Why Vulnerability Management Needs Engineering Input
Traditional vulnerability management often sorts by CVSS, exploit availability, and Internet exposure. That model misses specialized buses and embedded protocols. CAN-related vulnerabilities live in a domain where operational knowledge is crucial.Useful enterprise questions include:
- Which business units operate CAN-connected Linux systems?
- Are those systems centrally patched or vendor-managed?
- Do engineering workstations have attached CAN adapters?
- Can contractors or build agents run CAN test software?
- Are embedded images rebuilt from upstream kernels or vendor BSPs?
- Does the incident response team recognize kernel oops patterns from CAN subsystems?
Consumer and Developer Impact
For most consumer Linux desktop users, this vulnerability will be invisible. They are unlikely to use SocketCAN BCM, configure RTR responses, or attach CAN interfaces. Even many enthusiasts running Linux on laptops will simply receive the fix through a normal kernel update and never notice.Developers are a different audience. Embedded developers, automotive researchers, makers working with vehicle diagnostics, and Windows users combining WSL with Linux tooling may have exactly the kind of experimental setups where local boundaries are loose. A lab workstation with sudo access, USB CAN hardware, and multiple test scripts can become an unusually rich environment for triggering kernel edge cases.
What Developers Should Do
Developers should treat the fix as a good reason to review assumptions around local hardware access. If a test tool can crash the kernel accidentally, a malicious or malformed test can do the same deliberately. That matters in shared labs and training environments.Recommended developer actions include:
- Update your kernel before running new CAN BCM tests.
- Check custom kernel branches for the one-line locking fix.
- Use virtual CAN carefully in CI pipelines that run untrusted code.
- Separate experimental scripts from systems connected to real equipment.
- Capture kernel logs when testing RTR behavior.
- Document CAN permissions rather than relying on tribal knowledge.
Competitive and Ecosystem Implications
CVE-2026-23362 lands in a broader moment where operating system security is less about one vendor versus another and more about supply-chain speed. Linux now has a more formalized CVE pipeline for kernel issues, and that means many bugs that once appeared only as patches now appear in vulnerability dashboards. The result can look noisy, but it gives defenders better tracking.For Microsoft, the lesson is also strategic. The company ships, supports, and depends on Linux in WSL, Azure, containers, network appliances, and internal infrastructure. A Linux kernel advisory is no longer a competitor’s problem; it is part of the platform reality surrounding Windows.
The Market Signal
The most mature vendors will be judged not by whether they ever ship kernel bugs, but by how quickly they identify exposure, backport fixes, and communicate practical impact. Automotive and industrial vendors face particular pressure because customers often run long-lived devices that cannot be rebooted casually. Security teams increasingly expect SBOMs, kernel provenance, and clear patch lineage.This vulnerability also highlights a competitive advantage for platforms with strong update channels. Systems that can rapidly consume stable kernel fixes are less exposed to lingering medium-severity bugs. Systems frozen on vendor board-support packages may carry small kernel flaws for years.
Lessons for Kernel Engineering
From an engineering perspective, CVE-2026-23362 is about state sharing across paths. The transmit path initialized a lock because transmit operations obviously needed it. The receive path seemed separate until an RTR response required receive-side code to call transmit helper logic.That pattern is common in mature kernels. Features accrete over decades, and a subsystem that looks linear on a whiteboard may contain legacy behavior, callbacks, timers, filters, and exceptional paths. Security bugs often live in the gap between the mental model and the actual call graph.
Why One-Line Fixes Deserve Respect
A one-line patch can be more important than a thousand-line refactor when it corrects a fundamental invariant. In this case, the invariant is that anybcm_op capable of reaching bcm_can_tx() must have its transmit lock initialized. The patch makes the object safe for that path.The case also reinforces the value of fuzzing and automated bug discovery. The patch trail references syzbot reporting, which is exactly the kind of toolchain that finds strange combinations humans may not prioritize. Kernel security increasingly depends on this constant adversarial testing of edge paths.
Engineering takeaways include:
- Initialize synchronization primitives wherever shared helpers may be reached.
- Audit exceptional protocol flags after locking changes.
- Treat receive-to-transmit callbacks as full participants in transmit invariants.
- Use fuzzing results as design feedback, not just bug reports.
- Backport narrowly and consistently across stable branches.
Strengths and Opportunities
The handling of CVE-2026-23362 shows several strengths in the modern kernel security ecosystem. The bug was identified, fixed upstream, backported across multiple stable branches, assigned a CVE, and enriched by vulnerability databases within a visible timeline. That does not eliminate operational work, but it gives administrators the information needed to act.- Clear root cause: The missing
spin_lock_init()is easy to understand and verify. - Narrow patch: The fix is small, reducing regression risk compared with broad redesigns.
- Upstream visibility: Kernel, NVD, and distribution tracking provide multiple validation points.
- Stable backports: Multiple maintained branches received patch references.
- Good teaching value: The bug illustrates subtle interactions between receive and transmit paths.
- Actionable mitigation: Systems not using CAN BCM can often reduce exposure quickly.
- Better asset awareness: The CVE gives enterprises a reason to inventory CAN-connected Linux systems.
Risks and Concerns
The main concern is not that CVE-2026-23362 will sweep across the Internet. It is that specialized systems often sit outside ordinary patch workflows, and those are exactly the systems most likely to use CAN. A medium kernel bug can linger in embedded products long after general-purpose distributions have moved on.- Embedded lag: Vendor firmware may receive fixes later than mainstream Linux distributions.
- Operational downtime: CAN-connected systems may require carefully scheduled maintenance windows.
- Scanner noise: Generic findings may obscure which systems are truly exposed.
- Local boundary confusion: Containers, test agents, and shared accounts can weaken “local-only” assumptions.
- Custom kernels: Engineering teams may miss the fix if they maintain private kernel branches.
- Poor logging: Kernel crashes may be misattributed to flaky hardware or drivers.
- Legacy protocol use: RTR behavior may persist in older systems that no one has recently audited.
What to Watch Next
The next phase is distribution and vendor convergence. Upstream patches are only the beginning; the real security outcome depends on Ubuntu, Debian, Red Hat derivatives, SUSE, Android-adjacent embedded trees, appliance vendors, automotive Linux stacks, and Microsoft-managed Linux environments consuming and shipping the fix. Watch for advisories that map the upstream patch into specific package versions.Security teams should also watch whether scanners update detection logic beyond broad CPE matching. The best vulnerability management tools will help distinguish systems where CAN BCM is present and reachable from systems where the vulnerable code is dormant. That distinction matters for prioritization and maintenance planning.
Important follow-up items include:
- Distribution kernel advisories that list fixed package builds.
- Embedded vendor firmware updates for gateways and industrial controllers.
- WSL kernel release notes for users relying on Microsoft’s Linux kernel delivery.
- Container policy reviews for privileged workloads on CAN-enabled hosts.
- Post-patch stability reports from automotive and industrial test environments.
Source: NVD / Linux Kernel Security Update Guide - Microsoft Security Response Center
