Splunk is helping to build a safer and more resilient digital world by equipping customers with the unified security and observability platform they need to keep their organization securely up and running — no matter what digital disruptions come their way.
SAP is the leading enterprise application and business AI company. We stand at the intersection of business and technology, where our innovations are designed to directly address real business challenges and produce real-world impacts. Our solutions are the backbone for the world’s most complex and demanding processes. SAP’s integrated portfolio unites the elements of modern organizations — from workforce and financials to customers and supply chains — into a unified ecosystem that drives progress. SAP privacy statement for followers: www.sap.com/sps Our Community Guidelines At SAP, we're committed to fostering meaningful conversations that respect everyone in our community. To maintain a positive environment, we moderate comments that: • Target individuals personally, including our employees, customers, or partners • Contain discriminatory, harassing, or threatening language/content • Share personal information without consent • Promote misinformation or spam or 3rd-party links We believe in open dialogue and constructive feedback, but we will remove content that violates these guidelines without notice. We appreciate your understanding and contribution to a respectful community. For questions about our moderation practices, please DM or contact us at [email protected].
Security & Compliance Standards Overview
Splunk has 75.44% more incidents than the average of same-industry companies with at least one recorded incident.
SAP has 777.19% more incidents than the average of same-industry companies with at least one recorded incident.
Splunk cyber incidents detection timeline including parent company and subsidiaries
SAP cyber incidents detection timeline including parent company and subsidiaries
Last 3 Security & Risk Events by Company
Zerobyte is a backup automation tool Zerobyte versions prior to 0.18.5 and 0.19.0 contain an authentication bypass vulnerability where authentication middleware is not properly applied to API endpoints. This results in certain API endpoints being accessible without valid session credentials. This is dangerous for those who have exposed Zerobyte to be used outside of their internal network. A fix has been applied in both version 0.19.0 and 0.18.5. If immediate upgrade is not possible, restrict network access to the Zerobyte instance to trusted networks only using firewall rules or network segmentation. This is only a temporary mitigation; upgrading is strongly recommended.
Open Source Point of Sale (opensourcepos) is a web based point of sale application written in PHP using CodeIgniter framework. Starting in version 3.4.0 and prior to version 3.4.2, a Cross-Site Request Forgery (CSRF) vulnerability exists in the application's filter configuration. The CSRF protection mechanism was **explicitly disabled**, allowing the application to process state-changing requests (POST) without verifying a valid CSRF token. An unauthenticated remote attacker can exploit this by hosting a malicious web page. If a logged-in administrator visits this page, their browser is forced to send unauthorized requests to the application. A successful exploit allows the attacker to silently create a new Administrator account with full privileges, leading to a complete takeover of the system and loss of confidentiality, integrity, and availability. The vulnerability has been patched in version 3.4.2. The fix re-enables the CSRF filter in `app/Config/Filters.php` and resolves associated AJAX race conditions by adjusting token regeneration settings. As a workaround, administrators can manually re-enable the CSRF filter in `app/Config/Filters.php` by uncommenting the protection line. However, this is not recommended without applying the full patch, as it may cause functionality breakage in the Sales module due to token synchronization issues.
Zed, a code editor, has an aribtrary code execution vulnerability in versions prior to 0.218.2-pre. The Zed IDE loads Model Context Protocol (MCP) configurations from the `settings.json` file located within a project’s `.zed` subdirectory. A malicious MCP configuration can contain arbitrary shell commands that run on the host system with the privileges of the user running the IDE. This can be triggered automatically without any user interaction besides opening the project in the IDE. Version 0.218.2-pre fixes the issue by implementing worktree trust mechanism. As a workaround, users should carefully review the contents of project settings files (`./zed/settings.json`) before opening new projects in Zed.
Zed, a code editor, has an aribtrary code execution vulnerability in versions prior to 0.218.2-pre. The Zed IDE loads Language Server Protocol (LSP) configurations from the `settings.json` file located within a project’s `.zed` subdirectory. A malicious LSP configuration can contain arbitrary shell commands that run on the host system with the privileges of the user running the IDE. This can be triggered when a user opens project file for which there is an LSP entry. A concerted effort by an attacker to seed a project settings file (`./zed/settings.json`) with malicious language server configurations could result in arbitrary code execution with the user's privileges if the user opens the project in Zed without reviewing the contents. Version 0.218.2-pre fixes the issue by implementing worktree trust mechanism. As a workaround, users should carefully review the contents of project settings files (`./zed/settings.json`) before opening new projects in Zed.
Storybook is a frontend workshop for building user interface components and pages in isolation. A vulnerability present starting in versions 7.0.0 and prior to versions 7.6.21, 8.6.15, 9.1.17, and 10.1.10 relates to Storybook’s handling of environment variables defined in a `.env` file, which could, in specific circumstances, lead to those variables being unexpectedly bundled into the artifacts created by the `storybook build` command. When a built Storybook is published to the web, the bundle’s source is viewable, thus potentially exposing those variables to anyone with access. For a project to potentially be vulnerable to this issue, it must build the Storybook (i.e. run `storybook build` directly or indirectly) in a directory that contains a `.env` file (including variants like `.env.local`) and publish the built Storybook to the web. Storybooks built without a `.env` file at build time are not affected, including common CI-based builds where secrets are provided via platform environment variables rather than `.env` files. Storybook runtime environments (i.e. `storybook dev`) are not affected. Deployed applications that share a repo with your Storybook are not affected. Users should upgrade their Storybook—on both their local machines and CI environment—to version .6.21, 8.6.15, 9.1.17, or 10.1.10 as soon as possible. Maintainers additionally recommend that users audit for any sensitive secrets provided via `.env` files and rotate those keys. Some projects may have been relying on the undocumented behavior at the heart of this issue and will need to change how they reference environment variables after this update. If a project can no longer read necessary environmental variable values, either prefix the variables with `STORYBOOK_` or use the `env` property in Storybook’s configuration to manually specify values. In either case, do not include sensitive secrets as they will be included in the built bundle.
