Responsible Security Research: Public Evidence of Friday Works’ Authorised Testing Practice

What this public record demonstrates—and what it does not

Friday Works publishes this record to explain how we conduct responsible security research. It is evidence of a process: confirm scope, form a hypothesis, collect evidence, report to the right party and stop when the threshold is not met. It is not a list of vulnerabilities we claim to have found, and it does not replace a professional certification or a client penetration-test report.

The article was reconciled from local research notes before publication. Target names, account data, undisclosed details, commands and material that could recreate harmful behaviour were removed. The image below is a redacted record excerpt; it shows a lead being stopped rather than being inflated into a finding.

That is deliberate. A security claim is useful only when it can be independently assessed within a lawful boundary and the affected party has a chance to remediate before sensitive details spread.

Credible security research is not measured by the number of ideas or commands run, but by how it respects boundaries, evidence and the people affected.

How every test is authorised

Before work starts, the research owner records a written scope issued or approved by the programme or asset owner. The record names authorised assets, permitted activities, exclusions, rate limits, the testing window, the accountable contact and the reporting channel. No written scope means no test.

During the work, we use only researcher-controlled accounts and data, keep activity to the minimum needed to test a hypothesis and avoid accessing anyone else’s information. If a step could exceed scope, disrupt a service, change production state or touch sensitive data, it stops pending fresh approval.

Any change to the target, technique, schedule or impact level needs renewed authorisation. NIST describes information-security testing as planning, conducting, analysing findings and developing mitigation; in practice, the authorisation boundary is what makes those technical steps responsible.

From signal to conclusion: the evidence threshold

Research begins with a hypothesis, not a conclusion. In a mobile authentication or deep-link flow, an interesting source-code branch is only a signal. It does not prove that an external party can reach it, bypass a server-side check or create impact in a live environment.

A reportable record needs reproducible conditions, an observed result, a negative control that rules out another explanation, an authorised impact boundary and remediation context. If an approved environment or runtime confirmation is missing, the correct state is “unconfirmed,” not “critical vulnerability.”

That discipline protects both clients and the public. It avoids the two common errors: publishing an unsupported warning, or going too far in pursuit of proof. For a lead that does not qualify, the right output can be an internal note and a request for a safer validation condition.

A public example: cross-checking CVE-2026-27771 before writing

To illustrate source validation, we revisited CVE-2026-27771 after its public disclosure. An older research note described the affected surface incorrectly. The Gitea 1.26.2 release and the GitHub Security Advisory identify insufficient permission checks for Composer package source links in Gitea through 1.26.1, with the fix in 1.26.2.

Because this is a published advisory, Friday Works presents it only as open-source analysis, never as an original discovery. Operators should upgrade to the fixed version, review access to private and internal Composer packages, and test their own environment through an approved change process. This article does not provide exploit steps or directions for scanning third-party systems.

The small example reinforces a simple rule: before writing “we found,” return to the official source, affected version, patch and the evidence actually in hand. Correcting an earlier interpretation when better evidence appears is a sign of a mature research practice.

How we publish and report responsibly

A report that an owner can act on separates scope and authorisation, hypothesis, minimum reproduction, expected versus actual behaviour, evidence and controls, demonstrable impact and remediation guidance. CISA likewise asks researchers to explain independent confirmation and security impact instead of submitting only screenshots or large tool outputs.

Public material passes a different gate: publish only after details are public or authorised, and keep only defensive value such as validation method, patch, test limits and implementation lessons. We do not publish target identifiers, cookies, keys, user data, unpublished reports or details that would recreate an attack.

For a web or API assessment, Friday Works starts with an agreed scope, testing window and a deliverable a development team can use. The aim is to help a team fix and verify an issue—not to produce a sensational claim.