Every 4 hours

Cyber

Keywords match titles. Record type separates incidents, intel, and research from CVEs.

  1. Research · Jun 26, 2026 · ZeroDay Catalog

    Kestra OSS Vulnerability: OS Command Injection Risk Identified

    A significant OS command injection vulnerability has been discovered in Kestra OSS, allowing unauthorized access to execute workflows.

    What changed

    An OS command injection vulnerability has been identified in Kestra OSS, an open-source orchestration platform. This issue arises from the improper authentication mechanism in the AuthenticationFilter component, which allows unauthorized access to sensitive functionalities.

    Specifically, prior to versions 1.0.45 and 1.3.21, the system uses a suffix match to determine access to the public configuration endpoint, which can be exploited by attackers.

    Who is affected

    The vulnerability impacts users of Kestra OSS, particularly those who have not updated to the latest versions. The following groups are at risk:

    Organizations utilizing Kestra for event-driven orchestration without implementing additional security measures may find themselves exposed.

    • Kestra OSS users prior to versions 1.0.45 and 1.3.21
    • Developers relying on Kestra for workflow automation
    • Companies implementing Kestra in production environments
    • Security teams responsible for monitoring and securing orchestration platforms

    What to do

    It is crucial for affected users to take immediate action to mitigate the risk posed by this vulnerability. The following steps are recommended:

    Upgrade to the latest versions of Kestra OSS to ensure that the vulnerability is patched and that the authentication mechanism is secured.

    • Update Kestra OSS to version 1.0.45 or later, or 1.3.21 or later.
    • Review and tighten access controls for the public configuration endpoint.
    • Monitor for any unauthorized access attempts or unusual activity related to Kestra workflows.
    • Consider implementing additional security measures, such as network segmentation or enhanced logging.

    Original report

  2. Research · May 26, 2026 · ZeroDay Catalog

    Critical Vulnerability in Mirasvit Full Page Cache Warmer Allows Remote Code Execution

    A serious deserialization vulnerability has been identified in Mirasvit Full Page Cache Warmer for Magento 2, potentially allowing remote code execution by unauthenticated attackers.

    What changed

    A vulnerability has been discovered in Mirasvit Full Page Cache Warmer for Magento 2, specifically in versions prior to 1.11.12. This flaw involves the deserialization of untrusted data, which can be exploited by attackers to execute arbitrary code on the server.

    The issue arises from an unrestricted call to PHP's native unserialize() function, enabling attackers to inject crafted serialized PHP objects via the CacheWarmer cookie.

    Who is affected

    The vulnerability impacts multiple stakeholders, particularly those using the affected version of the Mirasvit Full Page Cache Warmer.

    Organizations utilizing Magento 2 with the Mirasvit extension are at risk of exploitation if they have not updated to version 1.11.12 or later.

    • Mirasvit Full Page Cache Warmer for Magento 2 (versions before 1.11.12)
    • Magento 2 users employing Mirasvit extensions
    • E-commerce platforms relying on Magento for their operations
    • Developers and system administrators managing Magento installations

    What to do

    It is crucial for affected users to take immediate action to mitigate risks associated with this vulnerability. Updating to the latest version of the Mirasvit Full Page Cache Warmer is strongly recommended.

    In addition, organizations should review their security protocols and consider implementing additional measures to protect against potential exploitation.

    • Upgrade to Mirasvit Full Page Cache Warmer version 1.11.12 or later.
    • Conduct a security assessment of your Magento 2 environment.
    • Monitor for any unusual activity that may indicate exploitation attempts.
    • Implement best practices for securing PHP applications, including limiting the use of unserialize() where possible.

    Original report