This is a public-safe write-up. Risk categories and business impact are described, but the specific mechanisms, locations, and reproduction steps behind each finding are deliberately withheld and shared only with the MediaFast team.
MediaFast, a Reddit and GEO marketing automation platform, commissioned an authorized external security assessment covering its website, application backend, user-facing tools, and integration system. The review confirmed several controls were already effective, documented two priority findings — one concerning information disclosure, one concerning trust extended to third-party software — and delivered a remediation plan with defined closure criteria and a verification retest. Specific findings are not published.
MediaFast is a Reddit marketing automation platform that brings together campaign workflows, analytics, user feedback, AI-assisted tools, and external integrations.
Because the product connects several services behind one account, the MediaFast team wanted to understand what an outsider could reach across the full platform. Unbreachable conducted an authorized external assessment of the website, application backend, user-facing tools, and integration system.
What we found
Several important protections were already working. Administrative actions rejected unauthenticated requests, the AI integration service required valid access, federated login tokens were properly verified, automated traffic was limited, and private file storage was not openly accessible. That mattered: it meant the review could focus narrowly instead of rebuilding confidence from the ground up.
The assessment documented two findings that warranted immediate attention, plus a set of smaller hardening opportunities.
The first concerned information disclosure. More detail about people was reachable than the product needed to make available. The business consequence — rather than the mechanism — is what made it a priority: information of that kind can be collected and reused for targeted spam, impersonation, or phishing against the very people the platform serves.
The second concerned trust extended to third-party software. Part of the platform granted standing automatically where a review step would have been safer. On its own this did not hand anyone access to a customer account, because a user still had to complete an authorization step deliberately — but it lowered the effort required to put convincing third-party software in front of users.
Alongside these, the assessment noted routine improvements around account privacy, protection of account-changing actions, browser-side safeguards, and how much technical detail was returned publicly.
The specific categories, locations, and mechanics behind each finding stay in the private report shared with MediaFast. A published case study should show what an assessment is worth without narrowing the search for anyone else, and that constraint applies to every write-up we publish.
There was no evidence in the assessment that MediaFast had suffered a confirmed breach. The work identified preventable exposure and trust gaps before they became a known incident.
What we recommended
Unbreachable delivered a remediation plan ordered by business impact rather than technical severity, structured so a small team could act on it directly:
- Findings ordered by realistic consequence for users and the business
- A concrete engineering action and owner defined for every item
- Explicit closure criteria — what must be true before an item counts as resolved
- Reduced public exposure of information the product does not need to publish
- A review step before third-party software is granted standing
- Removal of every artifact created during the assessment itself
- Baseline hardening of account actions and browser-side safeguards
- A verification retest of the affected journeys once changes were deployed
The report was equally explicit about what was NOT a security issue. Several pieces of normal platform behavior that a scanner or a cautious reader might flag were documented as expected and safe rather than inflated into findings — which kept the team's attention on the two items that genuinely mattered.
The outcome
MediaFast received a clear view of which controls were already doing their job and which areas created genuine customer or business risk.
The team left the assessment with a direct order of operations and defined closure criteria, ending in a focused verification test rather than an open-ended list.
By testing how the platform's separate systems connected rather than reviewing each feature in isolation, the assessment surfaced risk that a per-feature review would have been likely to miss.
Security considerations for marketing automation and integration platforms
General context for this category of product. It is not a description of MediaFast's assessment findings.
Marketing automation tools occupy a position of unusual trust. They act on a customer's behalf inside someone else's platform, hold audience and campaign data, and typically expose an integration surface so other software can plug in. Each of those properties is a reason the product is useful, and each one widens what an assessment needs to consider.
Information disclosure is the quiet risk in this category. Products built around community engagement naturally surface names, handles, and profile detail — that is often the point. The question is not whether information is shown but whether more is returned than the interface actually needs, because anything reachable in bulk can be collected and repurposed for targeted phishing or impersonation against the exact audience the platform is meant to serve.
Integration surfaces carry a second, subtler risk: trust granted automatically. Any platform that lets third-party software connect has to decide how much standing that software gets before a human reviews it. Even when the end user must still approve access deliberately, permissive onboarding lowers the cost of presenting something that looks legitimate. A review step before software gains standing is a cheap control against a problem that is expensive to unwind.
For teams in this space the practical lesson is to treat the integration boundary as a product decision rather than a configuration detail, and to ask of every public response whether it returns the minimum the interface requires.
Why this matters for other SaaS teams
Platforms that act on a user's behalf inside another service are trusted twice over — once by the customer, once by the platform they integrate with. Assessing the boundary between those systems is where an external review earns its value.
For any product exposing an integration surface, deciding deliberately how much standing third-party software receives before review is one of the highest-leverage security decisions available, and one of the cheapest to make early.
Frequently asked questions
Why is information disclosure treated as a serious finding when no password is involved?
Because impact is not limited to credentials. Contact and profile detail that can be collected in bulk becomes raw material for targeted phishing, impersonation, and spam. The people affected are the platform's own users, which makes it a trust problem as much as a technical one, even though nothing was 'broken into'.
What is the risk of open third-party integration registration?
It lets anyone create software that appears to belong to the ecosystem. Users normally still have to approve access, so it is not automatic compromise — but it reduces the effort needed to make something look legitimate, which is exactly the step a convincing consent-phishing attempt depends on. Requiring review before software gains standing removes most of that leverage.
Should a security report list things that are not vulnerabilities?
Yes. Explicitly documenting normal behavior that looks alarming — public documentation, the existence of a protected admin route, an authenticated internal service — prevents a team wasting time on non-issues and makes the genuine findings easier to trust. A report that inflates everything gets ignored.
How do you assess a platform that connects to an external service on a user's behalf?
By treating the connection as part of the product rather than someone else's problem: how access is obtained, how narrowly it is scoped, where users are returned afterwards, how it is revoked, and what happens if the software holding that access is not what it claims to be.
What does a verification retest actually confirm?
That the original impact can no longer be reproduced — not merely that code changed. A finding is only closed when the behavior that created the risk is gone and the fix has not introduced a new gap, which is why closure criteria are agreed up front rather than judged afterwards.
“Unbreachable found issues that mattered to our users and explained them without exaggerating the impact. The report showed us what was already secure, what needed immediate work, and how to verify the fixes properly.”
— Arthur, CEO of MediaFast