Security vulnerabilities

Severity: 4.3 — Medium

Target Feature: Shared cron daemon (/admin/cron/, platform-wide scheduler)

Vulnerability Class: CWE-208 — Observable Timing Discrepancy

Root Cause: alwaysdata's shared cron infrastructure uses a platform-level scheduler that processes tenant cron jobs sequentially within the same second window. When two tenants schedule jobs at identical times, execution delay is measurable. Additionally, the API endpoint GET /api/v1/cron/ returns a next_run timestamp that is computed differently depending on whether a conflicting job is already queued — creating a timing oracle.

Attack Narrative:
Step 1: Attacker registers an account and creates a cron job at * * * * * (every minute), noting the API-returned next_run value via GET https://api.alwaysdata.com/v1/cron/[id]/.
Step 2: Attacker creates dozens of additional cron entries at the same schedule and measures the progressive drift in next_run values (delta between creation timestamp and computed next_run).
Step 3: By correlating drift patterns at specific minutes of the day, attacker maps load spikes to specific time slots, inferring which tenants have cron jobs at those times and approximately how many — useful for fingerprinting high-traffic or high-value accounts.
Step 4: Cross-referencing with DNS/WHOIS data for co-hosted domains, attacker identifies competitor SaaS products running batch jobs and infers their processing schedules for competitive intelligence or targeted timing attacks.

Impact: Competitive intelligence leakage, inference of tenant operational patterns, targeted DoS scheduling to coincide with victim batch windows.

Remediation: Add uniform random jitter (±500ms–2s) to all next_run computations returned by the API. Process cron job queue entries in random order within each second window. Do not expose scheduler-computed next_run with millisecond precision in API responses.