Pushover offers optional end-to-end encryption for message content (https://pushover.net/api#e2ee): title, message and url are encrypted by the sender (gzip, then AES-256-CBC with PKCS#7 padding, then HMAC-SHA256 over IV + ciphertext, then base64), and only the Pushover app (iOS/Android 5.0+) can decrypt them. Pushover's servers then only see ciphertext.

The official Zabbix "Pushover" media type does not support this. Monitoring alerts often contain internal host names, IP addresses and service details, so optional e2ee would be useful.

The obstacle: the webhook JavaScript engine (Duktape) has no AES, no gzip and no cryptographically secure random generator.

To show that it is feasible within the existing webhook architecture, I built a proof of concept: https://github.com/toffelwurst/zabbix-pushover-e2e (v1.0.0, AGPL-3.0-only, derived from the official 8.0 media type)

• small pure-ES5 crypto library plus one patch block in the official script
• fail closed: an empty key or an unresolved macro is an error; e2e_key = off behaves exactly like the official media type
• handles Pushover's length limits on the encrypted strings (longer fields are rejected, not truncated, by Pushover)
• tested offline (Node crypto/zlib, openssl, FIPS-197 test vector), in Zabbix 8.0.0 (Duktape) and live against the Pushover API and app

It is a proof of concept, not a finished patch: the crypto code and especially the IV construction (HMAC-based, because Duktape has no CSPRNG) have not had an independent security audit. Its security notes and limits are documented in the README.

Suggestions, in order of preference:

1. Native crypto helpers in the webhook engine (AES-CBC, gzip/deflate, a CSPRNG), so media types can implement e2ee without shipping their own crypto.
2. Optional e2ee in the official Pushover media type, implemented and maintained by Zabbix; the proof of concept may serve as a reference (its license allows reuse).

Small related issue: the official Pushover media type reads params.priority_resolved for recovery messages but does not define that parameter, so recoveries always use priority_default (related to ZBX-26342, which also deals with the priorities of this media type).