A Note on the 2025 Storage Disclosure and Where Our Security Stands Today
In early 2025, a security researcher disclosed that a WorkComposer storage bucket was accessible without authentication. We closed that access after the disclosure reached us, removed the affected dataset, performed a full review of our storage configuration, and published this page so that anyone evaluating WorkComposer can read about the event and our response in our own words.
What happened
A storage bucket provisioned for a non-production environment was found to be accessible without authentication.
After we received the disclosure we closed the access path, removed the affected dataset, rotated the relevant credentials, and reviewed every storage location we operate to confirm that no other resource was reachable without authentication.
We are not aware of any access to the bucket beyond the researcher who reported it.
What we changed
Following the disclosure we reviewed every storage location used by WorkComposer and made the following changes permanent:
- Single defined storage path. All screenshot data captured by the WorkComposer desktop application is now written to one set of storage locations with a documented configuration. Non-production environments do not share storage with production data.
- Application-layer encryption of screenshots. Screenshot files are encrypted on the WorkComposer servers before they are written to storage. The encrypted bytes are what land in the bucket; the decryption keys are held outside the storage layer.
- No public access on data buckets. Storage buckets that hold customer data are configured to deny public access. Access is granted through authenticated API requests, not by direct object URLs.
- Configuration review on every storage account. New storage accounts, including customer-controlled storage that some customers configure for their own data residency reasons, are tested and validated before they are used.
- Internal review of access patterns. Every code path that reads or writes screenshot data was reviewed during the response, and a security review now runs against changes that touch storage, authentication, or session handling.
How WorkComposer protects screenshot data today
The current architecture is built around the principle that screenshot bytes leaving a user's machine should never be readable by anyone who has not been authenticated and authorised by the customer's organisation.
- Screenshots travel from the desktop application to our API over TLS.
- Screenshots are encrypted at the application layer before they are written to storage.
- Storage buckets for customer data are private; objects are not addressable by public URL.
- When a permitted user views a screenshot in the WorkComposer dashboard, the request goes through the API, where the requesting user's organisation membership, role, and per-feature permissions are checked before the object is read, decrypted, and returned.
- Account passwords are stored hashed with bcrypt. Two-factor authentication is available for accounts.
- Administrative actions inside customer organisations are recorded in an audit log that organisation owners can review.
- Customers who require data residency can configure their own AWS S3 or SFTP storage for their organisation's screenshots; in that mode WorkComposer never holds the data at rest.
We use ISO/IEC 27001 as a reference framework for our internal security practices across access control, cryptography, operations security, supplier relationships, and incident response. We do not currently hold an ISO 27001 certification. Where customers require certified attestation, we are happy to share what we do have on request.
FAQ
Was production data exposed?
The bucket in question was provisioned for a non-production environment.
Has the issue been resolved?
Yes. Public access was removed after the disclosure reached us, the dataset was removed from the affected bucket, and the underlying configuration was changed so that no storage location holding customer data is publicly readable.
What data does WorkComposer collect?
WorkComposer captures the data needed to operate a time-tracking and activity-monitoring product for the organisations that subscribe to it. This includes data such as screenshots, application and URL activity, keyboard and mouse activity counts, device and connection metadata, and the account profile of the user the customer organisation has invited. The capture behaviour is controlled by the customer organisation's administrators. A complete list of data categories and retention defaults is available on request.
How are screenshots stored today?
Screenshots are encrypted at the application layer on our servers before they are written to storage. The storage buckets are private; objects are reached through authenticated API requests, not direct URLs. Customers can also configure their own storage account if they prefer to keep the data in infrastructure they control.
How can security researchers reach WorkComposer?
Security reports can be sent to security@workcomposer.com. We respond to good-faith disclosures and we do not pursue legal action against researchers who report findings to us privately and give us a reasonable opportunity to fix them. We do not pay bounties at this time.
Is WorkComposer certified to a security standard?
We do not currently hold an ISO 27001 or SOC 2 certification. Our internal practices are organised around the ISO/IEC 27001 control families. We will update this page when that changes.
Where can I read more?
Customers and prospective customers can request additional detail — including a written description of our data flow, retention defaults, and sub-processor list — from security@workcomposer.com.
Last updated: