Bug bounty &
vulnerability disclosure.

Program overview.

Entrilex News Network LLC established its invitation-based paid bug-bounty program on April 25, 2025. The program was established to identify, investigate and remediate security vulnerabilities affecting company-operated digital publishing properties and supporting infrastructure. Participation in paid security testing is subject to prior authorization, defined testing scope, and agreed reporting and reward terms.

The program originally operated privately through direct, invitation-based arrangements with security researchers. Those engagements may have used individually agreed compensation terms. This public policy describes the reporting channel and current participation framework; it does not replace earlier written agreements.

Covered Properties.

We maintain security oversight of these Entrilex-operated digital publishing properties, including their relevant websites, content-management systems, applications, APIs and infrastructure under our administration.

On smaller screens, scroll the table sideways to read all columns.

Subdomains, additional properties, third-party integrations, cloud services, CDN infrastructure, hosting providers and external vendors are not automatically within the testing scope. Even where we administer an application, the underlying provider’s systems and other customers’ environments are excluded unless the relevant owner has separately authorized the activity.

You may report a suspected issue affecting a listed domain or another company-administered system. If control or ownership is uncertain, send the information already available and ask for clarification. Do not test to establish ownership.

Written testing authorization.

Each offensive-security engagement requires prior written authorization from Ehraz Ahmed — CEO & Security Lead and the relevant system owner. An invitation, acknowledgment of a report or inclusion in our portfolio is not sufficient on its own.

The approved rules of engagement must identify:

• Researchers: the named participants and the security lead and system owner approving the engagement. Permission cannot be transferred to other people.
• Assets: the exact hosts, applications, accounts, APIs and endpoints that may be tested, with explicit exclusions.
• Methods: permitted techniques, rate limits, test accounts, permitted tools and any restrictions on automation or exploitation.
• Timing: the approved testing window, time zone and any operational blackout periods.
• Data handling: minimum necessary evidence, approved storage and communication methods, access restrictions, retention and deletion requirements.
• Emergency procedures: how to stop testing immediately, reach the security lead and system owner, and escalate accidental exposure or service instability.
• Reporting and remediation: delivery deadlines, validation and retesting arrangements, disclosure terms, reward eligibility and agreed payment terms.

Approval must be obtained before expanding the assets, methods, participants or testing window. Entrilex may pause or withdraw testing authorization for operational or security reasons. Stop immediately when instructed; any restart requires written approval. This does not cancel payment obligations already agreed for eligible completed work.

Request an engagement at [email protected] using the subject Bug Bounty Authorization Request. Identify the proposed assets, methods and participating researchers. Testing may begin only after the written scope and required owner permissions have been confirmed.

Paid participation and rewards.

The paid program compensates eligible, authorized researchers under their written engagement terms. A qualifying finding must concern an approved asset, demonstrate a reproducible security weakness and provide enough sanitized technical evidence to validate its impact safely.

Proposed current reward guidance: the following amounts are suggested bands for newly approved engagements. They are not guaranteed awards, automatically approved commitments or evidence of historical payments. Entrilex must approve the applicable monetary terms in writing before active testing.

On smaller screens, scroll the table sideways to read all columns.

Eligibility and qualifying findings

• Paid participants must be invited, named and authorized in writing, legally able to enter the engagement and receive payment, and compliant with applicable legal and payment restrictions.
• Disclose conflicts of interest before participation. Employees or contractors responsible for the affected system are not eligible for a separate bounty unless their written terms expressly allow it.
• Findings must be original, reproducible and relevant to confidentiality, integrity or availability. Examples include validated injection, authentication or authorization flaws, exposed credentials, and exploitable CMS, plugin, dependency or configuration weaknesses.
• Reports must describe the affected asset, prerequisites, safe reproduction steps, demonstrated impact and supporting evidence. A scanner alert or a vulnerability label without validation is insufficient.
• Unsolicited reports are welcome but do not automatically qualify for payment. A report acknowledgment is not acceptance of a bounty claim.

Severity, duplicates and award decisions

The security lead evaluates exploitability, required privileges, affected data, operational impact, system sensitivity and report quality. CVSS may inform the assessment, but a score or vulnerability name alone does not determine the award. A minimal safe demonstration is sufficient; extracting production data or disrupting service is never required.

Unless the engagement states otherwise, the first complete, reproducible report of a previously unknown issue is considered for an award. Reports sharing the same root cause may be treated as one issue. Duplicates, known issues and already-remediated findings ordinarily do not receive a separate bounty; material new impact may be considered.

Entrilex determines validation, severity and awards under the approved engagement terms and communicates the outcome and a reason for any rejection or adjustment. Researchers may request reconsideration with additional evidence. Discretion does not override an existing written payment commitment.

Exclusions and payment arrangements

Unless expressly accepted in advance, discretionary exclusions include theoretical issues without practical impact, unvalidated automated output, missing security headers or version disclosures alone, unsupported software claims without demonstrated exploitability, and vulnerabilities affecting only independent vendors. Out-of-scope activity, prohibited methods, extortion or failure to follow agreed confidentiality and disclosure terms may make a finding ineligible, subject to the engagement terms.

The written arrangement must specify how the award will be approved and paid, including currency, payment method, payee verification, applicable tax documentation, any fees and payment timing or milestones. Do not send bank details or identity documents in an initial vulnerability report; request the approved protected channel. No universal payment deadline is promised by this page.

Historical private paid arrangements may have used individually agreed terms. These proposed ranges do not describe earlier payouts or retrospectively change an engagement.

Testing rules and data protection.

Use the least intrusive method permitted by the written scope. Keep traffic low, use approved test accounts and synthetic data, and stop once a safe proof of the vulnerability has been obtained. Protect news publishing, editorial communications and user services throughout the assessment.

• No unauthorized access: do not enter excluded systems, unrelated accounts or customer, subscriber, journalist or editorial information.
• No destructive activity or disruption: denial-of-service attacks, resource exhaustion, destructive testing and interference with news publishing are prohibited. Do not modify articles, databases, accounts or production configurations.
• No persistence: do not install backdoors, maintain unauthorized access, deploy malware or move laterally beyond approved assets.
• No data exfiltration: do not extract, bulk-download, copy or retain real personal, customer or editorial data. Use redacted evidence that demonstrates the issue without revealing sensitive content.
• No unapproved social engineering: phishing, impersonation or contact with employees, sources or users for testing requires explicit prior written approval identifying the participants and methods. Credential stuffing and uncontrolled password attacks are prohibited.
• No unapproved third-party testing: providers, vendors and integrations require the relevant owner’s permission and express inclusion in the engagement.
• Respect limits: follow approved rates, blackout periods, account restrictions, data-handling rules and all stop-work instructions.

If sensitive information is accidentally exposed or a service becomes unstable, stop immediately and notify [email protected] and the engagement’s emergency contacts. Report the affected system, time and nature of the exposure using redacted details. Do not investigate further, share the information or attempt a production fix without approval.

Store necessary evidence only in the approved location, restrict it to authorized participants, and follow the agreed retention and secure-deletion instructions. Coordinate the handling or deletion of inadvertently obtained data with the security lead, including any preservation required by law.

Security leadership.

Entrilex News Network LLC owns and administers the program. Ehraz Ahmed — CEO & Security Lead is accountable for research authorization, report triage, coordination with system owners, remediation oversight and bounty decisions.

We may work with authorized cybersecurity analysts, penetration testers and external security specialists. Depending on the written engagement, their work may include:

• Web application penetration testing and API security assessments.
• Vulnerability identification, validation and remediation verification.
• Malware investigation and reverse engineering of software used by the organization, where permitted by law and relevant rights holders.
• Dependency and supply-chain security reviews, including CMS and plugin assessments.
• Infrastructure configuration assessments and controlled adversarial-security exercises.

External participation does not transfer program ownership or create additional testing permission. Access, confidentiality and responsibilities must be defined for each engagement. Entrilex remains the accountable party.

Report a vulnerability.

Send reports confidentially to [email protected] with the subject Entrilex Security Vulnerability Report. You may use a pseudonym or report anonymously; a reply address helps us acknowledge and clarify the finding. Paid participation requires the identity and payment verification specified in the engagement.

1. Identify the affected domain, URL, endpoint, component or version and when the issue was observed.
2. Describe the vulnerability, prerequisites and expected versus actual behavior.
3. Include minimal safe reproduction steps and sanitized requests, logs, screenshots or proof-of-concept code where appropriate.
4. Explain the realistic impact without accessing additional data or extending the test.
5. State whether sensitive data, active exploitation or service instability was encountered, and whether testing has stopped.
6. For paid research, reference the written authorization, named participants, approved scope and test window. Include a preferred contact and any disclosure constraints.

Never include live passwords, access tokens, private datasets or unredacted personal information in ordinary email. Ask the security lead for a protected transfer method before providing sensitive evidence. Do not post reports in public comments or contact individual journalists about technical findings.

Acknowledgment and remediation

We aim to acknowledge reports within five business days when contact details are provided. This is a response target, not a guaranteed resolution deadline. If you do not receive a response, follow up in the same email thread and identify any urgent risk in the subject.

The security lead reviews scope and urgency, requests missing evidence, validates reproducibility, checks duplicates and assigns the finding to the relevant system owner. Confirmed issues are prioritized by demonstrated risk; mitigation, remediation and any authorized retest are coordinated with the researcher.

We aim to provide material status updates and explain validation and reward decisions. Resolution time depends on severity, reproducibility, affected systems and available remedies. Do not retest a fix unless your original authorization still covers the activity or new permission has been issued.

Safe harbor for good-faith activity.

For research performed in good faith within a valid written authorization and this policy, Entrilex will not initiate civil legal action or request a criminal investigation solely because of that authorized activity. To the extent we control a conflicting restriction in our own terms, we waive it only as necessary for the expressly authorized research.

We also will not pursue action solely for submitting a good-faith vulnerability report. That reporting commitment does not authorize the actions used to obtain a finding or provide retroactive permission for unauthorized access. An honest mistake should be reported immediately so we can understand what happened and limit harm.

These commitments extend only to Entrilex’s authority and rights. We cannot authorize access to third-party systems, bind vendors, other rights holders or public authorities, or provide immunity from applicable law. If a third party raises a concern about activity we authorized, we will confirm the scope of our authorization where lawful.

If an activity or asset is unclear, stop and request written clarification before proceeding. Permission to report and eligibility for a reward remain separate from authorization to test.

Confidential handling and disclosure.

Reports and evidence are handled on a need-to-know basis by the security lead, relevant system owners and any authorized specialists assisting with validation or remediation. We may need to involve an affected provider or meet a legal reporting obligation; personal information and sensitive evidence should be minimized in those communications.

Researcher attribution is optional. We will not publicly identify a researcher without consent, except where disclosure is legally required. Report records and payment details should be retained only as necessary for security follow-up, contractual, legal or accounting requirements, with access restricted accordingly. See our Privacy policy for the broader handling of personal information.

Report privately before publishing technical details. We will work with the researcher on a coordinated disclosure plan and ordinarily aim to discuss publication within 90 days of acknowledgment. This is a coordination target, not a guaranteed fix date or automatic permission to disclose confidential information.

Agree the publication date and the information safe to release in writing. If additional time is needed, discuss the reason, interim mitigations and a revised timeline. Do not publish personal data, live secrets or details that unnecessarily expose users or editorial operations to harm. Reward terms and any researcher credit should be addressed separately.

This policy does not restrict disclosures required or protected by law, or confidential advice from legal counsel. It does not require a researcher to waive legal rights in order to report a concern.

Program history and policy revisions.

The original private paid program establishment date is distinct from the dates on which this policy was revised. Current rules do not retrospectively alter prior authorized engagements or their agreed compensation terms.