CVE-2026-116207: YesWiki SQL Injection

How to Detect the YesWiki Vulnerability

Begin with web-server and reverse-proxy logs. Identify the route used by the Bazar entries search API in the local deployment, then search requests for suspicious parameter content. Logging formats differ, so the examples below are starting points rather than universal signatures. URL decoding may be required before matching backticks or SQL keywords.

A useful detection hypothesis is an unauthenticated request to the Bazar search endpoint where query or searchfields contains SQL metacharacters or timing functions. A single match is not proof of exploitation. Repeated matches, database delays, and abnormal response sizes should be escalated.

Example Log Searches

Example command-line triage against a URL-decoded or access-log export:

grep -Eai \
  '(/bazar|bazar.*search|searchfields|query).*(%60|`|SLEEP[[:space:]]*\\(|SELECT|UNION|SUBSELECT|information_schema)' \
  /var/log/nginx/access.log

If the access log records encoded parameters, inspect common encodings separately:

grep -Eai \
  'searchfields=.*(%60|%27|%22)|query=.*(%60|%27|%22)|SLEEP(%28|%2528)' \
  /var/log/nginx/access.log

For structured logs in an Elasticsearch-compatible environment, an illustrative query is:

http.request.uri.query:(
  *searchfields* OR *query*
) AND http.request.uri.query:(
  *%60* OR *`* OR *SLEEP* OR *UNION* OR *SELECT*
)

The exact field names and query syntax depend on the logging platform. Also review database logs for unusual SLEEP() calls, unexpected reads from user-account tables, or query latency spikes that align with suspicious HTTP requests.

If database general logging was disabled, the absence of evidence in those logs does not clear the system.

Mitigation and Patching

Upgrade affected 4.x installations to YesWiki 4.7.0 or later. Upgrade affected 5.x alpha installations to YesWiki 5.0.0-alpha4 or later, using the supported upgrade path for the deployment branch.

The supplied research does not establish whether every later release is supported for every installation. Administrators should select a vendor-supported release that includes the correction rather than copying files from an unrelated branch.

Before upgrading:

1. Back up the YesWiki application configuration and database.
2. Document the current version and deployment method.
3. Test the target release where possible.
4. Confirm the supported upgrade path.
5. Preserve relevant logs before making changes.

After the upgrade, confirm that the running web root and PHP process are using the corrected files. A package or container may have been updated while an older application directory remains active, so validate the deployed artifact rather than relying only on the package manager’s result.

Git-Managed Deployment Example

For a Git-managed deployment, an illustrative update sequence is:

cd /var/www/yeswiki

# Confirm the current state and create a rollback reference.
git status --short
git describe --tags --always
git tag "pre-CVE-2026-116207-$(date +%Y%m%d%H%M%S)"

# Fetch release metadata, then select the approved fixed release.
git fetch --tags --prune
git checkout 4.7.0

# Run the deployment's documented dependency, migration, cache, and service steps.

Do not run this blindly on a production installation. The correct branch, tag, dependency commands, ownership, and migration process depend on how YesWiki was deployed.

For a 5.x alpha deployment, select 5.0.0-alpha4 or later instead of 4.7.0. If the installation is archive- or package-managed, use the corresponding supported upgrade mechanism.

Temporary Exposure Reduction

Until patching is complete:

• Restrict access to the Bazar entries search API at a trusted reverse proxy or application firewall, where appropriate.
• Limit exposure to known networks if business requirements permit.
• Monitor requests to the endpoint closely.
• Avoid relying on generic keyword blocking, because encoding variations and SQL syntax can bypass simplistic filters.

These are temporary controls, not a substitute for upgrading.

Also review the database account used by YesWiki. Remove unnecessary permissions and ensure the account cannot access unrelated administrative databases or tables. If logs indicate that password hashes or other credential material may have been read, rotate affected credentials and invalidate sessions according to the organization’s incident-response procedures. Investigate before deleting evidence.

Organizations evaluating endpoint protection alongside application controls may also find this EDR buyers’ guide for macOS useful for broader workstation visibility.

Incident-Response Checklist

If suspicious activity is found:

1. Preserve web-server, reverse-proxy, application, and database logs.
2. Record affected YesWiki versions, hosts, IP addresses, and database instances.
3. Upgrade to a fixed version using the supported deployment process.
4. Review database access for user, credential, and password-hash tables.
5. Check for unusual account creation, privilege changes, or configuration changes.
6. Rotate potentially exposed credentials and invalidate sessions.
7. Review authentication logs for follow-on activity.
8. Document whether data access or service degradation was confirmed.
9. Continue monitoring after remediation.

Do not assume that a successful upgrade removes evidence of earlier exploitation. Retain relevant artifacts according to the organization’s incident-response and legal requirements.

References

The primary reference is the NVD record for CVE-2026-116207:

• NVD: CVE-2026-116207

The YesWiki GitHub Security Advisory pages provide project-specific advisory context:

• YesWiki GitHub Security Advisory: GHSA-ccp2-6q93-hggh
• YesWiki GitHub Security Advisory: GHSA-hgxv-w4r8-8877

Additional vulnerability information is available from VulnCheck:

• VulnCheck: YesWiki 4.6.0 Before 4.7.0 SQL Injection via Bazar Entries Search API

For exploitation-status verification, consult the CISA catalog directly:

• CISA Known Exploited Vulnerabilities Catalog

At the time covered by this assessment, CVE-2026-116207 was not listed in CISA KEV, and no verified in-the-wild exploitation or CVE-specific public PoC had been identified. Recheck these sources before publishing an updated incident or exposure assessment.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.