Sample of remediated vulnerabilities

Field	Value
Document title	Sample of remediated vulnerabilities
Version	1.0
Effective date	29 May 2026
Owner	security@theorahq.com
Approved by	Theora Security Lead
Review cadence	Quarterly, and on any in-scope security merge to main

0. Document control history

Version	Date	Author	Change summary
0.1	15 May 2026	Security Engineering	Initial extraction of remediated security merges from main for the SOC 2 evidence window.
0.9	22 May 2026	Security Lead	Severity ratings reviewed and verification steps added for each entry.
1.0	29 May 2026	Security Lead	Approved for publication on the Trust Center and submission to the SOC 2 audit evidence package.

1. Purpose

This document publishes a sample of security vulnerabilities that Theora has identified and remediated in the production codebase backing the betaapp-api Cloud Run service in Google Cloud project tactile-stack-491017-c0 (region us-central1). Each entry corresponds to a real merge commit on the main branch of the LouizaLab/BetaApp repository on GitHub, and each is independently verifiable by an auditor or customer through the referenced commit SHA. The sample is drawn from the current SOC 2 audit window and demonstrates that Theora’s vulnerability management process produces measurable, code-level outcomes rather than tracking metadata alone.

2. Scope

The evidence covers the application tier (Django 4.2 on Python 3.14), the data tier (Cloud SQL for PostgreSQL on private IP via the betaapp-connector Serverless VPC Access connector, and the tactile-stack-491017-c0-betaapp-assets Google Cloud Storage bucket), the identity tier (Firebase Identity Platform with MFA via TOTP and SMS and Argon2 password hashing), the logging tier (Cloud Logging with the core.logging.RedactingFilter), and the build and deploy pipeline (Cloud Build, configured by cloudbuild.yaml, triggered on push to main, with Firebase Hosting in front of Cloud Run). The current production revision serving 100% of traffic is betaapp-api-00070-lnq.

3. How to verify the entries in this sample

Every row in the table in section 4 cites a merge commit SHA on the main branch of LouizaLab/BetaApp. An auditor with read access to the repository can confirm each remediation by running, for example:

git fetch origin main
git log --oneline --merges --since="2026-05-01" --until="2026-05-31" origin/main
git show 

The resulting diff, commit message, and merge metadata constitute the primary evidence. Production confirmation is available by inspecting the running revision betaapp-api-00070-lnq in Cloud Run, which was built from main at or after each of the SHAs below.

4. Sample of remediated vulnerabilities

#	Date	Merge SHA	Vulnerability class	Description	CVSS-like severity	Remediation evidence / how to verify
1	2026-05-13	f9cc2c1	Authentication abuse / brute-force exposure	Prior to this change, Theora’s authentication endpoints accepted unbounded request volume from a single source IP, which exposed the login and credential-validation surface to credential-stuffing, password spraying, and enumeration patterns. The feature/rate-limiting branch introduced per-IP rate limiting on the authentication endpoints fronted by the betaapp-api Cloud Run service, capping request bursts and rejecting abusive sources before they reach Firebase Identity Platform. The control complements Firebase’s native abuse protections and reduces the blast radius of leaked or guessed credentials. Verification: git show f9cc2c1 displays the rate-limit middleware, configuration, and tests; the behaviour can be observed live against the production revision by sending a burst of authentication requests from a single source and confirming that excess requests are rejected.	Medium-High (auth abuse, ~CVSS 5.0–7.5)	git show f9cc2c1 on origin/main; live behaviour visible on revision betaapp-api-00070-lnq.
2	2026-05-13	d1edc6d	Sensitive data exposure via application logs	Before this change, Django application logs forwarded to Cloud Logging could contain raw user query content, which created a secondary copy of potentially sensitive user input outside the primary data store and outside the data-retention controls applied to the database. The feature/query-log-redaction branch added core.logging.RedactingFilter, a Django logging filter that strips user query content from log records before they are emitted to Cloud Logging. The filter is wired into the root logger configuration so that every log handler in the application benefits from it by default. Verification: git show d1edc6d shows the filter implementation, the logging configuration that installs it, and unit tests that assert query content does not survive into emitted log records. An auditor can additionally inspect recent Cloud Logging entries in project tactile-stack-491017-c0 for the betaapp-api service and confirm that user query payloads do not appear.	High (data exposure via logs, ~CVSS 7.0+)	git show d1edc6d; sample Cloud Logging entries from betaapp-api in tactile-stack-491017-c0.
3	2026-05-13	39a4056	Insufficient defense-in-depth on data at rest	The tactile-stack-491017-c0-betaapp-assets GCS bucket was previously protected only by Google-managed encryption keys, which meets baseline confidentiality requirements but does not give Theora direct control over the key lifecycle. The feature/cloud-kms-cmek branch placed the bucket under a Customer-Managed Encryption Key (CMEK) backed by a Cloud KMS data-key with a 90-day rotation policy, so that Theora controls and can revoke the key material that protects asset objects at rest. Verification: git show 39a4056 shows the Terraform / configuration changes that bind the bucket to the KMS key; the live binding is observable via gcloud storage buckets describe gs://tactile-stack-491017-c0-betaapp-assets and via the Cloud KMS key’s rotation schedule in the console.	Medium (defense-in-depth on data at rest)	git show 39a4056; gcloud storage buckets describe output for the bucket; KMS key rotation policy.
4	2026-05-13	a468e3d	Authentication correctness on fresh sign-up	A regression in the sign-up flow caused newly created Firebase Identity Platform accounts to fall through to an incorrect identity-resolution branch on their first authenticated request, which could result in the application failing to identify the freshly signed-up user correctly during the session bootstrap. While the issue did not grant access to another user’s data, an auth-correctness defect of this kind is treated as a security issue under Theora’s policy because it touches identity resolution. The feature/identify-firebase-fallback branch corrected the fresh-signup login flow so that the canonical Firebase identity is resolved on the first request, with regression tests covering the fresh-signup path. Verification: git show a468e3d shows the corrected identification logic and the accompanying tests.	Medium (auth correctness)	git show a468e3d; regression tests in the identify-firebase-fallback change set.
5	2026-05-13	50a8675	Data minimization / retention overreach	Without an automated retention job, expired user query data could remain in the primary data store beyond the documented retention window, increasing the exposure surface in the event of a compromise and weakening Theora’s data-minimization posture. The feat(retention): auto-delete expired user query data change introduced a daily delete_expired_queries Django management command that runs on a schedule and removes user query records that have passed their retention window from Cloud SQL for PostgreSQL. The job is idempotent and logs a count of removed records (with the query content itself redacted by core.logging.RedactingFilter). Verification: git show 50a8675 shows the management command, its scheduling, and tests; the job’s daily execution and per-run record count are visible in Cloud Logging for the betaapp-api service.	Medium (data minimization)	git show 50a8675; daily execution log entries for delete_expired_queries in Cloud Logging.

5. Severity rating method

Severity is expressed using a CVSS-like band rather than a strict CVSS v3.1 vector, because several of these findings are application-logic or configuration issues that do not map cleanly onto CVSS metrics. The bands used are:

• High — issues that, if left unremediated, could expose sensitive user data or credentials at scale (CVSS-equivalent 7.0 and above).
• Medium-High — issues that materially increase the attack surface against authentication or session boundaries (CVSS-equivalent 5.0–7.5).
• Medium — defense-in-depth, identity-correctness, and data-minimization issues that meaningfully reduce risk when fixed but do not by themselves grant unauthorized access (CVSS-equivalent 4.0–6.5).

6. Relationship to other Theora controls

The remediations in this sample are reinforced by the surrounding control environment documented elsewhere on the Trust Center and in the repository, including: the inventory of in-scope resources (docs/soc2/inventory-of-resources.md), the risk register (docs/soc2/risk-register.md), the vendor sub-processor list covering Google Cloud, Firebase, Anthropic, OpenAI, GitHub, and Vanta (docs/soc2/vendor-list.md), and the documented Cloud IDS exception (docs/soc2/cloud-ids-exception.md). Network-layer monitoring for the same workload is provided by VPC Flow Logs enabled on all 42 in-scope subnets at a 50% sample rate with include-all metadata.

7. Continuous evidence

New security-relevant merges to main are appended to this sample on the quarterly review cadence noted in the document control header, and on each in-scope security merge. Because every entry is a real merge SHA on a public-or-audit-accessible branch, this evidence is self-refreshing: an auditor or customer can re-run the verification commands in section 3 at any time and obtain the same result.

8. Contact

Questions about this evidence, including requests for read access to a specific commit for verification, may be directed to security@theorahq.com.