Andrew

**Name of the Vulnerable Software and Affected Versions** gittuf versions prior to 0.14.0 **Description** An attacker with push access to the Reference State Log (RSL) can roll back the current policy to any previous policy trusted by the current set of root keys. This occurs because gittuf determines the policy to load by inspecting the RSL and validates new policies by checking if their root metadata is signed by the required threshold of the current policy's root keys. Consequently, an attacker can create a new RSL entry referencing an old, trusted policy to revert the system to a chosen state. This attack is limited to policies still trusted by the most recent root keys and requires the attacker or the hosting forge to have push access to the RSL. **Recommendations** Update to version 0.14.0 or later. After upgrading, a root of trust user or policy administrator must run the `gittuf trust increment-version` or `gittuf policy increment-version` command to add the monotonically increasing number field to the metadata.

**Name of the Vulnerable Software and Affected Versions** FreePBX versions 15.0.19.87 through 15.0.19.88 FreePBX versions 16.0.18.40 through 16.0.18.41 **Description** The issue allows remote attackers to execute arbitrary code. This has been exploited in the wild, with reports of attacks starting in December 2021. The attacks involved implanting web shells on VoIP servers, allowing for the execution of arbitrary commands on the compromised communication server. The goal of the attackers was to establish persistence and enable further exploitation of the host system. The attacks were linked to IP addresses in the Netherlands and DNS records referencing Russian websites. **Recommendations** For FreePBX versions 15.0.19.87 through 15.0.19.88, update to version 15.0.20. For FreePBX versions 16.0.18.40 through 16.0.18.41, update to version 16.0.19. As a temporary workaround, consider disabling the restapps module until a patch is available. Restrict access to the vulnerable Rest Phone Apps module to minimize the risk of exploitation. Avoid using the vulnerable versions of restapps until the issue is resolved.