TL;DR
- Printerpix store their uploaded files in an S3 bucket
- The S3 bucket is publicly accessible and has indexing enabled
- This allows uploaded photos to be enumerated and viewed by any Internet user
- Disclosure was difficult as the only interface was one customer services email address
- Vulnerability was silently fixed around 70 days after disclosure
A bucketful of photos
There are many services that allow digital photos to be converted to prints. These include a plethora of other printing services so that customer photos may be converted to picture books, mugs, magnetic photo tiles, clothing or even a throw.
With the combination of destination, these services allow photos to manipulated in their web frontend, to be rescaled and altered to better fit the output.
It was noticed that whilst using one of these providers, Printerpix, all photos were uploaded to an S3 bucket and then were loaded directly from the bucket to aid in the scaling and manipulation of images.
Out of curiosity the bucket’s home was visited and it was noticed that the bucket allowed indexing, meaning that all the files stored in the buckets could be identified and the files downloaded.
Technical details
A bucket is a cloud-based storage concept – it is a place where files can be placed and retrieved by their key. The concept maps closely to a filesystem with a directory and filename which is referred to as a “key”. This makes it very easy to integrate cloud storage into an existing process.
Buckets from all major providers can also have temporary access tokens which are signed to that specific key and request. This allows a security method to allow the upload and download of files with access restricted to one individual request.
An alternative is to allow the bucket and key to be open to the public, which allows any user with the exact key for the file to access it through a web browser with no parameters.
A bucket may have indexing enabled, this means that if a directory key is provided than the contents of that directory can be indexed, so that all keys in that directory can be viewed and can then use that key to access the file directly.
When a file is uploaded to Printerpix, there is a set of standard requests:
First a POST request to /designer-q/ which details the image size, a JSON file is returned which contains the S3 key and upload URL for this image, this upload URL has an access token and is signed so can only be used by this request.
Notice the value of x-amz-acl in the JSON response. A PUT request is made to the provided upload URL that uploads the raw image.
Later requests included a GET request to the bucket with the key for that image:
This identified that the bucket used could be accessed through the URL: https://storage-ssd-01.printerpix.co.uk/userfiles
Visiting that URL showed that indexing was open, which returns an XML document listing all the keys for all files stored within. By default AWS S3 will only show a maximum of 100 keys, but as the files date back to 2021, it was estimated that there were millions of files within the bucket.
As the index could be accessed, the keys could be obtained and used to access the contents of the images.
Reporting and disclosure
The disclosure timeline is below:
11/08/2026: Initial disclosure
11/08/2026: Received generic “thank you response”
20/08/2026: Reminder sent
07/09/2026: Received a response with a named member of the support team, a ticket number was generated
11/09/2026: Second reminder sent
11/09/2026: Received generic “thank you response”
14/09/2026: Further details sent including URLs to demonstrate vulnerability
14/09/2026: Received a statement that “I would like to reassure you that Printerpix customers’ personal data and photographs are safe and are not accessible or downloadable by others. Customers cannot access another customer’s account, projects, or photographs through the Printerpix platform.”
14/09/2026: More details sent
15/09/2026: Received an email for another person’s problem
15/09/2026: Received an apology for the previous email
15/10/2026: Third reminder sent
20/10/2026: Checked current status and identified that it had been resolved, was not notified by Printerpix.
21/10/2026: Decided to publish as the vulnerability has been fixed
Disclosure was an interesting exercise, Printerpix had neither a security contact, a security.txt file, a security DNS record or subscribed to any bug bounty program. The only contact details on the website was a generic contact us email address at [email protected]
Being sent an email for a different customer shows serious failure in managing the customer support mailbox, although there was nothing confidential in the email, just a first name it was concerning. I received an apology for this, but I wonder whether the other customer was notified.
Advice
Using cloud features like buckets is an attractive option for quickly rolling out a product with lots of potential flexibility, but ensure that security features are used to protect any data stored within the cloud.
In this case, the developers knew about S3 access tokens and signing as they used them for the upload process, but at some point, a decision was made to make the images publicly accessible. Even then, complex filenames were used so that risk would have been minimised except that indexing was enabled on the bucket.
This strongly suggests that the product has not been fully pen tested to identify all security risks. This is a trivial to exploit vulnerability that any technical user who followed the upload process could have identified.
Printerpix resolved the vulnerability by migrating to a different cloud provider and seems to have configured the permissions on the new store to be more secure. At this point we decided to publish, as the vulnerability had been fixed.
The vulnerability disclosure was on par with companies that do not have a security function. Adding a security contact email address, a security.txt file or even a security DNS record are simple actions that can allow security researchers to disclose responsibly and reduce the length of time a vulnerability is open.
A lack of dialogue with the researcher was also a concern, that we weren’t told that it had been resolved showed a concern over how customer data was being managed.
There are other concerns with Printerpix’s use of cookies, ad tracking and communication to third parties that seem to ignore the state of the cookie dialogue box, that could make for future vulnerability disclosure.
