Vulnerability & Patch Log (Evidence 8.2.1)

Owner: Dr Simon Chapman (CTO) Reviewed and Approved By: Dr Serena Haywood (SIRO) Last SIRO Review: March 2026 Next Review: June 2026 Last Updated: 1 September 2026 (djangorestframework 3.16.1 -> 3.18.0 — CVE-2026-73228 and CVE-2026-73229 resolved)

Threat intelligence is sourced from NCSC Early Warning, GitHub Security Advisories, and OWASP and is reviewed as a standing item in our quarterly security meeting. Significant threat intelligence events are recorded in this log.

Monitoring Tools: pip-audit, ggshield (via pre-commit), GitHub Dependabot, CodeQL.

1. Active Vulnerability Exceptions (Open & Ignored)

Current Status: 4 active exceptions. All are dev-only transitive dependencies of isolated pre-commit tooling (ggshield/pip-audit); none ship to production. Monitoring for upstream fixes.

Our security scanning pipeline otherwise operates with zero vulnerability exceptions. All dependencies are monitored in real-time and any new vulnerabilities will cause immediate CI/CD pipeline failure.

2. Application-Layer Security Findings (August 2026 Deep-Dive)

A full static security review of the CheckTick codebase was performed on 01/08/2026 (see security-review-august-2026.md). These are application-layer findings (not dependency CVEs) identified by source review. They are tracked here so they appear alongside the dependency vulnerability record. Remediation is via atomic PRs with regression tests.

No Critical findings. No patient data exposure at rest. The two High findings (F6, F12) are recorded as resolved near-misses NM-02 and NM-03 in the Incident & Near-Miss Log. F12 remediation removed SVG upload support, added regression coverage, and confirmed through a production audit that no legacy SVG media existed. F1 remediation replaced slash-prefix checks with Django's url_has_allowed_host_and_scheme, constrained redirects to the current host, and requires HTTPS when the request is secure. Regression tests confirm protocol-relative, backslash-normalised, and external URLs are rejected while valid local redirects are preserved; successful signup still marks the email unconfirmed, redirects to the home page, and displays the confirmation notice. F2 remediation added the missing team and organisation invitation Markdown templates, restoring Django autoescaping before Markdown-to-HTML conversion, and explicitly escapes all dynamic values in the template-missing fallbacks. Regression tests cover both invitation types and both normal and fallback rendering paths. F7 remediation replaced the three inline /tmp/llm_response_*.json dump sites in checktick_app/surveys/llm_client.py with a single _write_llm_debug_dump helper that writes to settings.BASE_DIR / "logs" / "llm" with mode 0o600 (directory 0o700), prunes files older than 24h on each call, omits the outgoing messages payload (so user prompts are never written to disk), and is blocked in production unless LLM_DEBUG_DUMP_INSECURE=1 is also set. Regression tests in tests/test_llm_debug_dump_security.py cover the disabled case, the private directory and file modes, the messages-omission invariant, the production gate, the insecure-flag override, the 24h retention pruning, and an end-to-end check that ConversationalSurveyLLM.chat routes dumps through the helper. F8 remediation removed all anonymous access from the datasets API: the only anonymous consumer (professional-fields.js, which fetched dataset options into professional-field dropdowns on the survey respondent page) was replaced by server-side rendering via _get_professional_dataset_options() in checktick_app/surveys/views.py, the misleading IsOrgAdminOrCreator permission class was replaced by DataSetAccess (authentication required for every action, non-safe methods rejected), and the AllowAny override on the available-tags action was removed. Queryset scoping (global + own org + own individual datasets) is retained as defence in depth. Regression tests in checktick_app/api/tests/test_dataset_api.py assert anonymous list/retrieve/available-tags requests are denied, and checktick_app/surveys/tests/test_anonymous_access.py asserts anonymous respondents on public surveys receive server-rendered professional-field options with no client-side /api/datasets/ call.

F18 remediation (identified during the follow-up audit of the dataset web views performed as part of the F8 work): the SNOMED snapshot view dataset_snomed_snapshot created new datasets without enforcing the dataset-creation permission, allowing read-only org roles (VIEWER, DATA_CUSTODIAN) to create org-visible datasets; it also assigned snapshots to the user's first organisation regardless of role. The view now calls require_can_create_datasets before any work and assigns the snapshot only to an organisation where the user is ADMIN or CREATOR (personal dataset otherwise). The dataset detail template gates the snapshot/clone buttons on the real can_create_datasets permission, and the misleadingly-named context-processor flag was renamed can_view_datasets. Regression tests in checktick_app/surveys/tests/test_dataset_views.py cover denied anonymous/VIEWER/DATA_CUSTODIAN snapshot attempts, permitted CREATOR and individual-user snapshots with correct org assignment, and hidden buttons for VIEWERs.

F13 remediation: survey_style_update in checktick_app/surveys/views.py now validates icon_url at write time, accepting only http://, https://, and root-relative / paths and rejecting javascript:, data:, file:, and vbscript: schemes. The same validation was added to the platform-level SiteBranding.icon_url / icon_url_dark fields in checktick_app/core/views.py. As defence in depth, a new _sanitise_brand_overrides helper (using is_safe_url from checktick_app/core/theme_utils.py) re-checks icon_url and font_css_url at read time across all five survey views that build brand_overrides (survey_detail, survey_preview, survey_dashboard, survey_groups, group_builder), so values written via admin, import, or legacy data that bypass the write-time validator are still neutralised before reaching respondent-facing templates. Regression tests in checktick_app/surveys/tests/test_xss_creation_forms.py cover javascript:/data:/file:/vbscript: rejection, safe http(s):// and relative-path acceptance, and a defence-in-depth read-time guard asserting a javascript: URI stored directly in survey.style is not rendered on the public survey take page.

F16 remediation: sanitize_css_block in checktick_app/core/theme_utils.py was strengthened to strip { and } (preventing CSS rule breakout from the wrapping [data-theme="..."] { ... } rule) and url() references plus bare http(s):// URLs (preventing CSS-based data exfiltration via background-image: url(attacker/?...)), in addition to the existing < / > strip that prevents </style> breakout. The fallback in checktick_app/context_processors.py was updated to match. The existing usage renders theme_css_light/theme_css_dark as --var: value; declarations inside a fixed [data-theme] rule, so the input only ever needs values — never rule blocks or external URL loads — so stripping {} and url() is safe for the intended input. Regression tests in checktick_app/core/tests/test_theme_utils.py cover angle-bracket breakout, curly-brace breakout, the combined brace + url() exfiltration scenario, and preservation of safe --var: value; declarations. End-to-end tests in checktick_app/surveys/tests/test_xss_creation_forms.py assert a } [data-theme='custom'] { background: url(...) } payload stored in survey.style.theme_css_light does not produce a usable CSS rule on the dashboard or group-builder pages.

F9 remediation: per the review's recommended fix #3, style-src 'unsafe-inline' is retained because hCaptcha and DaisyUI genuinely require inline styles, and the relaxation is documented in checktick_app/settings.py (comment on the style-src directive) and docs/security-overview.md (§A03 XSS Prevention → Content Security Policy). The CSS-injection surface that 'unsafe-inline' would otherwise expose is mitigated server-side by the strengthened sanitize_css_block (F16), which strips {, }, and url() references so injected CSS cannot form new rules or exfiltrate via background-image: url(...). Regression tests in checktick_app/core/tests/test_csp.py assert the CSP header is emitted, style-src does not allow a bare wildcard origin, script-src does not carry 'unsafe-inline', and the 'unsafe-inline' relaxation is documented in both settings.py and docs/security-overview.md so the accepted risk is auditable.

F14 remediation: the GoCardless webhook handler in checktick_app/core/views_billing.py verified the HMAC-SHA256 signature correctly but had no replay protection — a captured body+signature could be replayed indefinitely to re-run payments.confirmed, subscriptions.created, and refund handlers, duplicating Payment rows, re-sending welcome emails, and re-triggering other side effects. A new WebhookEvent model (checktick_app/core/models.py, migration 0026_webhookevent) stores each processed GoCardless event id with a unique=True constraint on event_id. The payment_webhook handler now wraps each event in a transaction.atomic() block that calls WebhookEvent.objects.get_or_create(event_id=event_id) before dispatching; if the row already exists the event is skipped (logged at INFO) and no handler runs. Event routing was extracted into a single _dispatch_gocardless_event helper so the idempotency guard is the one chokepoint for every resource type (subscriptions, payments, refunds, mandates). The idempotency row is created before the handler runs, so a crash mid-handler rolls back both the side effects and the idempotency row (GoCardless retries the event on the next webhook). Events missing an id are skipped with a warning. A read-only WebhookEventAdmin provides an audit view of processed events. The review's recommended fix #2 (timestamp freshness) was investigated and confirmed not applicable: GoCardless's Webhook-Signature header is a bare HMAC-SHA256 hex digest of the body with no timestamp, so event-id idempotency is the primary defence. Recommended fix #3 (per-handler idempotency as defence in depth) is retained and now backed by a database constraint: handle_gocardless_payment_confirmed still guards duplicate Payment rows via payment_id, refund handlers still deduplicate via _refund_event_already_logged against the audit trail, and a partial unique constraint payment_provider_payment_id_unique on Payment.payment_id (migration 0027_payment_provider_payment_id_unique, condition payment_id != '') enforces at the database level that a replayed payments.confirmed cannot create a duplicate Payment row even if the WebhookEvent idempotency record is missing. The constraint is partial so manual/offline payments with a blank payment_id remain allowed (the platform admin refund view and refundable-payments query both anticipate blank payment_id records). These are now a second layer behind the event-id guard. Regression tests in tests/test_billing.py::TestWebhookReplayProtection cover: replaying a subscriptions.created event does not re-send the welcome email; replaying a payments.confirmed event does not re-activate a PAST_DUE subscription or duplicate the Payment row; distinct event ids in the same webhook are all processed (the guard does not over-block); and the partial unique constraint rejects duplicate non-empty provider payment ids while allowing multiple blank payment_id manual payments.

F3 remediation: checktick_app/settings.py now fails fast when ENVIRONMENT=production and SECRET_KEY is unset or empty, raising ImproperlyConfigured at startup with a message directing the operator to set the SECRET_KEY environment variable (e.g. openssl rand -base64 50). Previously SECRET_KEY = env("SECRET_KEY") or os.urandom(32) silently fell back to a per-worker random key, so each gunicorn worker (and each process restart) derived a different key, intermittently breaking sessions, CSRF tokens, signed cookies, and password-reset / email-confirmation tokens across workers with no log entry or exception. The random fallback is retained for development only and now uses os.urandom(32).hex() so the value is a serialisable string. Regression tests in checktick_app/core/tests/test_settings_hardening.py assert that an unset/empty SECRET_KEY in production raises ImproperlyConfigured on settings import, that a correctly-set production SECRET_KEY imports cleanly, and that the random fallback is still permitted in development.

F4 remediation: the global DRF default permission class in checktick_app/settings.py (REST_FRAMEWORK.DEFAULT_PERMISSION_CLASSES) was changed from rest_framework.permissions.IsAuthenticatedOrReadOnly to rest_framework.permissions.IsAuthenticated, so any future viewset that forgets to declare permission_classes ships fail-closed (no anonymous read access) rather than silently exposing anonymous read. Endpoints that genuinely require anonymous access (/api/health, /api/docs, /api/redoc, /api/schema, and the available-tags action) already declare AllowAny explicitly, so no behavioural change is expected. An audit of grep -r "permission_classes" checktick_app/api/ confirmed every existing viewset declares its intent. Regression tests in checktick_app/api/tests/test_api_hardening.py assert the global default is IsAuthenticated and that an anonymous GET against a deliberately-undeclared-permission viewset is denied (401/403). The full API test suite (38 tests across tests/test_api_*.py and checktick_app/api/tests/) passes with no regressions.

F11 remediation: APIKeyAuthentication.authenticate in checktick_app/api/authentication.py now throttles the last_used_at write to at most once per 60 seconds per key using a Django cache marker (apikey_lastused:{api_key.id}). On each authenticated request, the cache is consulted; only if the marker is absent is last_used_at updated and the marker set with a 60s timeout. This removes the synchronous per-request UPDATE on UserAPIKey (which under concurrent load serialised on the row lock for that key and added avoidable write traffic to the primary) while preserving the documented "last seen" purpose of the field — last_used_at is now at most ~60s stale, which is acceptable. Regression tests in checktick_app/api/tests/test_api_hardening.py assert that three requests within the throttle window produce only one last_used_at write, and that after the cache marker is cleared the next request refreshes the timestamp.

F5 remediation: the email_utils module docstring (checktick_app/core/email_utils.py) now documents the convention that all outbound email bodies must be rendered through .md Markdown templates via render_to_string so Django's autoescaping applies before Markdown-to-HTML conversion, and explicitly warns that f-string interpolation of cross-user controlled values (inviter names, team names, survey titles) bypasses autoescaping and reintroduces the F2 HTML-injection class. Self-only builders (where the only interpolated user content is the recipient's own data) are not exploitable, but the f-string pattern is flagged as fragile so any future builder that interpolates a cross-user value into an f-string will be caught at review. Regression tests in checktick_app/core/tests/test_security_review_docs.py assert the module docstring references .md templates, autoescaping, and the f-string risk.

F10 remediation: the finding was located in HealthcareLoginView (checktick_app/core/oidc_views.py), which passed request.GET.get("next") straight into the template context without validation. On audit, HealthcareLoginView was dead code — never wired into the URL config and its reverse("oidc:oidc_authentication_init") call used a namespace that does not exist (oidc_urls.py explicitly removed app_name), so the view would have raised NoReverseMatch if called. The live login page is /accounts/login/, served by TwoFactorLoginView (a subclass of Django's LoginView), whose get_context_data only exposes next via get_redirect_url() → url_has_allowed_host_and_scheme, so unsafe next values never reach the SSO/traditional-login hrefs on the live page. Remediation removed the dead HealthcareLoginView class and its orphaned registration/healthcare_login.html template, and added regression tests in checktick_app/core/tests/test_oidc_auth.py asserting the dead view stays removed, the live login page does not leak an unsafe next into its rendered SSO links, and legitimate relative next URLs still propagate.

F15 remediation: docs/llm-security.md §4 was rewritten to clarify that the security boundary is output validation + manual review + no tool access, not the system prompt. Instruction-based role enforcement is now explicitly framed as a deterrent, not a security control, and the docs no longer claim "strict role enforcement" as a protection mechanism or imply the model "reliably" refuses injection. The revised section states that modern LLMs are susceptible to prompt-injection techniques that bypass instruction-based defences, that the system prompt is published by design (so extraction is a non-issue), and that any future LLM feature must rely on output validation + manual review for its security boundary. Regression tests in checktick_app/core/tests/test_security_review_docs.py assert the docs no longer contain "strict role enforcement", do contain "output validation", and frame instruction-based enforcement as a "deterrent".

F17 remediation: HealthcareOIDCCallbackView (checktick_app/core/oidc_views.py) no longer mutates the process-global django.conf.settings object to switch between Google and Azure providers. The previous try/finally block that stored originals, overwrote settings.OIDC_RP_CLIENT_ID / OIDC_RP_CLIENT_SECRET / OIDC_OP_TOKEN_ENDPOINT / OIDC_OP_USER_ENDPOINT / OIDC_OP_JWKS_ENDPOINT / OIDC_RP_SCOPES with Azure values, called super().get(), and restored in finally has been removed entirely. Provider-specific config is now resolved per-request in two places, neither of which touches global settings: (1) HealthcareOIDCAuthView continues to set provider-specific instance attributes (via _configure_google_settings / _configure_azure_settings) for the authorization-request URL; (2) CustomOIDCAuthenticationBackend.authenticate (checktick_app/core/auth.py) re-resolves the provider endpoints/credentials from the OIDC_PROVIDERS dict onto the backend instance before the token exchange runs — this is the critical fix, because the backend is instantiated fresh by Django's authenticate() and its __init__ reads Google defaults from global settings. Without this, Azure callbacks would hit Google's token endpoint with Azure credentials. Regression tests in checktick_app/core/tests/test_oidc_auth.py assert (a) the Azure callback path does not mutate any of the six global OIDC settings attributes, (b) the backend uses Azure endpoints and credentials for an Azure session (verified by capturing the token-exchange payload), (c) the backend uses Google endpoints for a Google session, and (d) the callback view no longer carries a get_settings override (provider resolution belongs in the backend).

Previously Active Exceptions (Now Resolved - January 2025)

The following vulnerabilities were previously silenced but have been fully remediated through dependency architecture improvements:

2. Recently Remediated Patches (Closed)

Verified history of security updates applied. Real-time evidence is available in the CheckTick GitHub repository under the dependencies label and closed issues.

3. Automation & Triage Process

1. Continuous Auditing: Our Security Scan GitHub Action runs on every Push, Pull Request, and daily at 06:00 UTC.
2. Hard Block on Production: If pip-audit detects any vulnerability (Critical, High, Medium, or Low), the build fails and deployment is automatically blocked. No exceptions are configured.
3. Isolated Security Tooling: Security scanning tools (ggshield, pre-commit) run in isolated environments managed by pre-commit, preventing their dependencies from constraining production packages.
4. Zero-Exception Policy: Since January 2026, we maintain a zero-exception policy for vulnerability scanning. This ensures immediate visibility and remediation of any new vulnerabilities.
5. Endpoint Sync: Developers are required to run poetry install locally to synchronize their development environment with the latest patched versions in poetry.lock, preventing 'version drift' between local and production environments.

4. Architecture Improvements (January 2026)

Key Change: Separated security scanning tool dependencies from application runtime dependencies.

Before:

• Security tools (ggshield) were installed via Poetry alongside application dependencies
• Security tools pinned critical dependencies (cryptography, urllib3) to outdated versions
• Required maintaining an exception list of 10+ vulnerabilities
• Could not update vulnerable dependencies without breaking security tools

After:

• Security tools run in isolated pre-commit environments
• Production dependencies are free to update immediately when patches are released
• Zero vulnerabilities in production dependency tree
• Zero exceptions required in CI/CD pipeline
• Improved security posture and maintainability

This architectural change represents a significant improvement in our security monitoring capability while simultaneously reducing our vulnerability exposure.

5. CDN Artifact Handling & Integrity (January 2026)

Change: Updated automated CDN library refresh workflow to use npm pack as the canonical source for packaged JavaScript assets and to compute SRI from the package contents.

• Reason: Downloading files directly into the repository root from third-party CDNs caused temporary artifacts to remain after workflow runs (triggering security scanners such as CodeQL). Using npm pack ensures the registry is the authoritative source and the artifact bytes are reproducible.
• What changed: The update-cdn-libraries GitHub Action now:
• Runs npm pack <pkg>@<version> in a temporary directory
• Extracts the tarball, finds the minified asset, computes SHA-384 SRI from the file bytes, and atomically moves the asset into checktick_app/static/js/
• Cleans up temporary files and directories using traps to avoid leaving files in the repository
• Outcome: SRI values are computed from the exact npm package bytes; temporary files no longer appear in the repo root; CodeQL false-positives reduced.

Evidence: PR #155 updates the workflow and documentation to reflect this change and records the refreshed SRI evidence.