The Cronicle team takes security very seriously. Due to the nature of how Cronicle is installed on large server fleets a lot of decisions are made with security being the priority, and we always aim to implement security by design.

Cronicle uses the non-secret API key ID and title for object and audit attribution. Authentication keys supplied in request headers, query strings, or JSON bodies are removed from request data before authenticated API operations proceed.

Older releases stored raw API keys in categories, events, and audit records. Category and event responses, login data, browser updates, and job detail responses now omit the legacy api_key attribution field. This response filtering does not erase historical storage, logs, backups, or copies already retrieved by a user.

When upgrading an affected installation, revoke and replace keys that were used to create categories or events, or otherwise exposed in historical records. Update the integrations that use those keys, and review retained records and logs for cleanup. Upgrading alone does not invalidate an exposed key.

Chain reactions are unavailable to non-administrator users and API Keys with either category restrictions (cat_limit) or server group restrictions (grp_limit) enabled. This applies even if the allowlist currently includes every category or server group. Administrators are exempt from the account restriction, but cannot remove an event or job's permanent restriction.

Cronicle enforces this policy with a server-owned Boolean field named chain_disabled:

The UI, APIs, and plugin responses cannot clear chain_disabled. Supplying false, null, zero, or omitting the field does not remove an existing flag. The field is not a user-configurable switch. Creating another event with an existing event ID is rejected.

Restricted accounts cannot configure nonempty chain, chain_error, or chain_params values. Nobody, including an administrator, can add these settings to a flagged event or job. Empty values may clear old settings. An API edit that omits old chain settings may leave them stored, but the permanent flag prevents their execution. The event editor explains the restriction and clears those settings when saving.

The restriction applies to success chains, failure chains, scheduler launch-failure chains, and chains requested dynamically through plugin output. Blocked runtime attempts are logged. Normal job execution and non-chain updates continue. The flag survives queues, delayed retries, detached execution, and shutdown reruns. Queued launches also check the current event's flag, and chain execution checks the current source event in case it was flagged after a job started.

A flagged event can still be the target of a chain started by an unrestricted event and job. It runs with its restriction intact and cannot start another chain. Unrestricted accounts retain chain reactions for unflagged events and jobs.

There is no automatic migration or retrospective scan of event ownership, edit history, or current account privileges. Existing events without chain_disabled remain unflagged until a restricted account successfully edits them. Changing an account's privileges alone does not flag its saved events or already-running jobs. Existing scheduled events may therefore continue to initiate chains after upgrading, including chains requested by their plugins.

Please review existing events and scripts that restricted accounts could previously edit. Remove unwanted chains and dynamic chain directives, or save the event through a restricted account to apply the permanent restriction. Disabling an event does not stop an already-running job; review and abort those jobs separately when needed.

There is no UI or API operation to re-enable chaining on a flagged event. If chaining is needed again, an administrator or unrestricted account must review the event and its plugin parameters, then create a new event with a new ID. Review incoming chain references and integrations when replacing an event. Keep events that need chaining under unrestricted-account management, since any later successful restricted-account edit permanently disables their outgoing chains.

Cronicle follows the coordinated vulnerability disclosure model when dealing with security vulnerabilities. This was previously known as responsible disclosure. We strongly urge anyone reporting vulnerabilities to Cronicle or any other project to follow this model as it is considered as a best practice by many in the security industry.

If you believe you have identified a security vulnerability or security related bug with Cronicle please make every effort to contact us privately using one of the contact options below. Please do not open an issue, do not notify us in public, and do not disclose this issue to third parties.

Using this process helps ensure that users affected have an avenue to fixing the issue as close to the issue being made public as possible. This mitigates the increasing the attack surface (via improving attacker knowledge) for diligent administrators simply via the act of disclosing the security issue.

Several contact options exist however it's important you specifically use a security contact method when reporting a security vulnerability or security related bug. These methods are clearly documented below.

Users can utilize GitHub's security vulnerability system to privately report a vulnerability. This is an easy method for users who have a GitHub account.

Users can utilize the security@pixlcore.com email address to privately report a vulnerability. This is an easy method of users who do not have a GitHub account.

This email account is only accessible by members of the core team for the purpose of disclosing security vulnerabilities and issues within the Cronicle code base.

1. The user privately reports a potential vulnerability.
2. The report is acknowledged as received.
3. The report is reviewed to ascertain if additional information is required. If it is required:
   1. The user is informed that the additional information is required.
   2. The user privately adds the additional information.
   3. The process begins at step 3 again, proceeding to step 4 if the additional information provided is sufficient.
4. The vulnerability is reproduced.
5. The vulnerability is patched, and if possible the user reporting the bug is given access to a fixed binary, docker image, and git patch.
6. The patch is confirmed to resolve the vulnerability.
7. The fix is released and users are notified that they should update urgently.
8. The security advisory is published when (whichever happens sooner):

• The CVE details are published by MITRE, NIST, etc.
• Roughly 7 days after users have been notified the update is available.

Users who report bugs will at their discretion (i.e. they do not have to be if they wish to remain anonymous) be credited for the discovery. Both in the security advisory and in our documentation.