Appwrite Templates EUVD-2026-63579

The github-issue-bot template must be deployed as a publicly accessible function endpoint with a GITHUB_TOKEN configured with write access to at least one GitHub repository. The sole triggering condition is omitting the X-Hub-Signature-256 HTTP header - no authentication, no special tooling, and no account is required. Exploitation is limited to deployments using appwrite/templates ≤ 1.1.2; other Appwrite templates or Appwrite core are not affected by this issue. The blast radius is bounded by the permissions of the configured GITHUB_TOKEN: a token restricted to a single repository limits the attacker's ability to post comments to that repository only. No user interaction is required.

The CVSS 5.8 with vector AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N is appropriate: the attack is trivially executable over the network without credentials or complexity, and the Scope:Changed metric reflects that the configured GITHUB_TOKEN is leveraged to affect GitHub repositories outside the vulnerable application boundary. Real-world risk is bounded by deployment prevalence and GITHUB_TOKEN permissions - if the token is scoped narrowly, the attacker can only post comments on repositories where it holds write access. No EPSS data was provided and the vulnerability is not listed in CISA KEV, indicating no confirmed widespread exploitation. However, the zero-barrier attack (omit one HTTP header, craft a JSON body) means any exposed deployment is trivially abusable. The 'Jwt Attack' tag in the source intelligence is a miscategorization - this is an HMAC webhook bypass, not a JWT flaw. Confidentiality impact is correctly rated None; the only real-world consequence is unauthorized GitHub comment posting, which carries reputational and social-engineering risk (e.g., posting malicious links under the bot's identity) rather than data exfiltration.

An attacker sends an HTTP POST to the publicly accessible github-issue-bot function endpoint, omitting the X-Hub-Signature-256 header and supplying a JSON body with attacker-chosen 'repository', 'issue', and 'sender.login' fields. The inverted condition in verifyWebhook returns true, main.js continues to postComment, and the deployment's GITHUB_TOKEN posts an attacker-crafted comment to the specified GitHub issue. The attacker can repeat this against any repository accessible by the token, for example to post phishing links or impersonate bot activity on public issues.