Page

Security Policy

Last updated: June 30, 2026

This Security Policy explains how to report a security issue involving binghesoft.com. The site runs on WordPress and may use hosting tools, plugins, caching, security controls, and operational scripts. Security reports help keep the site available and protect readers, editors, and the wider network.

Reporting A Vulnerability

Send security reports to [email protected] with the subject line “Security Report”. Include the affected URL, a short description, steps to reproduce, screenshots if helpful, and any request IDs or timestamps. Do not include exploit code beyond what is needed to explain the issue safely.

Responsible Testing

Do not perform destructive testing, social engineering, spam, credential attacks, denial-of-service testing, data exfiltration, or attempts to access accounts that are not yours. Testing should be limited to confirming the issue without damaging the site or exposing private data.

What To Report

Useful reports can include authentication bypass, exposed sensitive files, unsafe redirects, cross-site scripting, plugin vulnerabilities affecting this site, misconfigured public backups, broken access controls, or security headers that create clear risk. Reports about outdated public information, ordinary spam, or general best-practice suggestions may be handled as normal site feedback.

Response Process

We review reports as time allows. Clear, reproducible reports are easier to act on. If a report is valid, we may patch the theme, update or disable a plugin, change hosting settings, purge cache, rotate credentials, or contact the hosting provider. We may not provide a detailed public timeline for every issue.

No Bug Bounty

Binghe Soft does not currently run a paid bug bounty program. Submitting a report does not create a right to payment, employment, or public credit. If public credit is appropriate, it should be agreed before publication.

Security Contact File

The site also publishes a `security.txt` file at `/.well-known/security.txt` so automated tools and researchers can find the security contact path.

Plugin And Hosting Issues

Security reports may involve WordPress core, the active theme, plugins, hosting cache, redirects, or access rules. A report is more useful when it identifies which layer appears to be involved. For example, a stale cached 404, a plugin rate limit, and a real PHP error require different fixes.

Confidentiality

Please give the editorial desk reasonable time to review a valid report before public disclosure. Do not publish exploit details, private data, or steps that would allow others to attack the site. If the issue is already being actively exploited, say that clearly in the report so it can be prioritized.

Out Of Scope

Some findings are useful but not treated as urgent security issues. Examples include missing cosmetic headers, broad plugin version observations without a working impact, username enumeration that does not expose private data, and reports generated only by automated scanners without manual verification. These can still be sent as site feedback, but they may not receive the same priority as a reproducible vulnerability.

After A Fix

After a security fix, the site may need a cache purge and a short verification pass. If you reported the issue, you may be asked to confirm that the behavior changed. Do not retest in a way that causes load, data exposure, or disruption.