প্লাগইনের নাম	Add Multiple Marker
দুর্বলতার ধরণ	ভাঙা অ্যাক্সেস নিয়ন্ত্রণ
সিভিই নম্বর	CVE-2025-11999
জরুরি অবস্থা	কম
সিভিই প্রকাশের তারিখ	2025-11-10
উৎস URL	CVE-2025-11999

Urgent: Add Multiple Marker (<= 1.2) — Missing Authorization Allows Unauthenticated Settings Update (CVE-2025-11999)

তারিখ: 11 November 2025
লেখক: WP-ফায়ারওয়াল সিকিউরিটি টিম

---

সারাংশ

• Severity: Low (CVSS 5.3)
• Affected software: Add Multiple Marker WordPress plugin (versions <= 1.2)
• Vulnerability class: Broken Access Control — missing authorization for settings updates
• Required privilege: Unauthenticated (no login required)
• CVE: CVE-2025-11999

This post is written from the perspective of WP-Firewall — a WordPress security service and managed WAF provider — and is aimed at site owners, administrators, and developers who need practical guidance to mitigate risk immediately and harden their sites against this type of flaw.

---

সুচিপত্র

1. What the vulnerability is (plain language)
2. Why it matters — real-world risk scenarios
3. How the issue typically appears in plugin code (what developers got wrong)
4. High-level attack vector (non-actionable description)
5. Indicators of compromise and forensic checks for site owners
6. Immediate mitigation steps for site administrators (without waiting for vendor patch)
7. Recommended WAF / virtual-patching rules and approach (for hosts and security teams)
8. Long-term remediation and coding best practices for plugin authors
9. Incident response: what to do if you believe you were exploited
10. How WP-Firewall helps: free protection and upgrade options

---

1) What the vulnerability is (plain language)

The Add Multiple Marker plugin versions up to 1.2 contain a broken access control issue: unauthenticated web requests can update the plugin’s settings. In short, the plugin exposes an endpoint or action that allows arbitrary settings changes without validating who is making the request. That means an attacker with only the ability to send HTTP requests to your site can change plugin configuration values.

Missing authorization in settings-update flows is a common, avoidable mistake. While the immediate result is “only” a changed option, that change can be leveraged for follow-on attacks depending on what settings are adjustable (redirect URLs, API keys, feature toggles, stored HTML, or callbacks). Because the issue requires no login, many sites are exposed until site owners harden access or the plugin is patched.

---

2) Why it matters — real-world risk scenarios

Although this particular finding is rated low (CVSS 5.3), the practical impact depends on what the plugin allows to be set. Typical dangerous outcomes include:

• Persistent configuration changes: An attacker could change redirect URLs, break site functionality, or enable dangerous plugin features.
• Data exfiltration or service misuse: If the plugin stores API keys, endpoints, or credentials, those could be altered to capture data or route traffic through malicious services.
• Privilege escalation chains: A seemingly harmless settings update could enable another vulnerability (for example, a stored XSS or an admin-notification path) that then results in full site compromise.
• Reputation and SEO damage: Redirects, spammy settings, or hidden links inserted via settings can hurt search rankings and user trust.
• Supply-chain exposure: If you use the plugin across multiple sites, automated attacks can modify configurations at scale.

Because the attacker does not need to be authenticated, this class of flaw is especially attractive for automated scanning and broad attacks.

---

3) How the issue typically appears in plugin code (what developers got wrong)

From a secure-coding perspective, there are common mistakes that lead to unauthenticated settings updates:

• Missing capability checks: The code updates options directly (update_option, update_site_option) or writes to the database in response to an HTTP request without checking current_user_can(‘manage_options’) or a similar capability.
• No nonce verification: Nonces protect actions initiated from valid admin pages. If an endpoint accepts requests without verifying a nonce (or uses nonces only when a user is logged in), an unauthenticated request will succeed.
• Publicly exposed action handlers: Using admin-ajax.php or the REST API with a publicly registered action/route but not requiring authentication or appropriate permission callbacks.
• Unsanitized inputs: Not only are inputs accepted from unauthenticated sources, but they may also be stored without sanitization — compounding the risk by enabling stored XSS, open redirects, or injection.
• Missing CSRF/authorization separation: Confusing authentication with authorization or assuming that a request “came from the admin UI” is not sufficient.

Developers should ensure both authentication and authorization checks are in place for any code path that writes configuration or takes privileged actions.

---

4) High-level attack vector (non-actionable)

An attacker discovers the plugin exposes a settings-update endpoint that does not require authentication. They craft an HTTP request that carries setting keys and values. The plugin accepts the request and writes the supplied values into the site’s options table (or equivalent storage). The attacker then tailors those setting changes to achieve their objective (redirect visitors, change API endpoints, add malicious content, enable debug features, etc.).

I am intentionally not providing step-by-step exploit payloads. The purpose here is to explain the nature of the vector so site administrators can detect and defend against it.

---

5) Indicators of compromise and forensic checks for site owners

If you use the Add Multiple Marker plugin (<= 1.2) or similar plugins, check the following for signs of abuse:

Configuration checks

• Inspect the plugin’s settings page in the WP admin for unexpected values (redirect URLs, API endpoints, email addresses, tokens, or toggles enabled that you didn’t enable).
• Check the wp_options (or wp_{prefix}_options) table for plugin-specific option names. Look for recent modifications to those rows (compare with backups if available).
• Search the database for common suspicious values such as unfamiliar domain names, base64 blobs, or script tags.

Access logs & webserver logs

• Look for repeated POST requests to admin-ajax.php, wp-admin/admin-post.php, or plugin-specific endpoints from unknown IPs or user agents.
• Check for requests that include suspicious parameters, or that happened at odd hours in volume patterns.

File system & content checks

• Look for new or modified theme/plugin files (timestamps that don’t match your updates).
• Verify that no new admin users have been created.
• Search page content and postmeta for injected links or scripts.

অ্যাপ্লিকেশন লগ

• If you have audit logging enabled (activity logs plugins, external logging), search for changes to plugin settings or update_option calls originating from unauthenticated contexts.

Backup comparison

• Compare the current database to a recent backup to find differences in plugin options or other suspicious changes.

If you find changes and you cannot explain them, treat the site as potentially compromised and move to incident response (see section 9).

---

6) Immediate mitigation steps for site administrators (without waiting for an official plugin patch)

Because the plugin currently has no official fix available, these mitigation steps are designed to reduce attack surface quickly:

1. Remove or disable the plugin if you are not actively using it
   • The simplest and most reliable mitigation is to deactivate and delete any plugin that is not essential to your site.
2. Restrict access to plugin endpoints with web server rules
   • Use .htaccess (Apache) or Nginx location rules to block direct access to plugin PHP files or to restrict admin-ajax.php/post endpoints to authenticated users or known IP addresses where feasible.
   • Example: only allow GET for certain endpoints, block POST unless from known sources (avoid sharing exact rules if you’re not comfortable editing server config — coordinate with your host).
3. Apply hardening to wp-admin
   • Protect wp-admin with HTTP Basic Authentication or IP whitelisting at the webserver level.
   • Restrict access to admin AJAX and admin-post handlers where possible.
4. Implement a WAF rule or virtual patch (see next section)
   • Block requests that match the plugin’s settings-update action patterns or suspicious POST payloads.
   • Rate-limit requests to admin-ajax.php and plugin endpoints to slow down automated scanners.
5. নজরদারি এবং সতর্কীকরণ
   • Set up alerts for writes to plugin-related options in the database (if your logging stack supports it) or for unusual POST traffic to admin endpoints.
6. Rotate secrets
   • If there’s any chance plugin-stored tokens or API keys were exposed or modified, rotate those keys immediately.
7. Backup and snapshot
   • Make an immediate backup (files & database) and isolate it. If you later need to investigate, you’ll have a clean snapshot for forensics.
8. স্টেকহোল্ডারদের অবহিত করুন
   • If your site is multi-tenant or provides services to others, inform affected parties and prepare to escalate incident handling.

These steps lower the immediate risk without requiring the plugin author to publish a patch.

---

7) Recommended WAF / virtual-patching rules and approach

For hosts, security teams, or site owners with a web application firewall (WAF) or managed filtering solution, virtual-patching is the fastest way to defend sites when a vendor patch is not yet available.

Recommended generic rule set (high-level guidance):

• Block unauthenticated POSTs that attempt to update plugin-specific option keys or contain payloads targeting known option names.
• Block or rate-limit POST requests to admin-ajax.php or admin-post.php carrying parameters that match plugin action names or suspicious parameter patterns.
• Enforce required headers: require a valid WordPress-origin header for state-changing requests (e.g., verified Referrer header pointing to your site) — but be cautious: this can interfere with legitimate API clients.
• Require valid WordPress nonces for requests that would normally be sent from the admin UI (where possible).
• Block requests containing common attack payload fragments (script tags, base64-encoded content) to likely settings fields that should never contain such data.
• Geo-block or reputation-based block: temporarily limit requests from regions or IP ranges with no legitimate visitors if the site is targeted.
• Alert on configuration writes: when a request leads to an option update, log and alert for human review.

Design considerations:

• Start with detection-only (monitoring) rules, then move to blocking as you validate false-positive rates.
• Implement rules at both edge (CDN/WAF) and origin (server-level) for defense-in-depth.
• Make virtual patches specific to plugin behavior to avoid impacting unrelated functionality.

WP-Firewall approach (how we would protect customers)

• Rapid rule creation that blocks the unauthenticated update action by matching the request method, endpoint, parameters and known patterns used by the plugin.
• Low false-positive, targeted rules that are safe to deploy across many sites.
• Option to escalate to stricter blocking for vulnerable plugin installations until an official fix is available.

(If you are a WP-Firewall customer, our managed rules are applied automatically under the free tier for critical known attacks — see the free plan section below for details.)

---

8) Long-term remediation and coding best practices for plugin authors

Plugin authors must treat any code path that changes site state as requiring both authentication and authorization. Here are checklist items for secure plugin design:

• Always check capabilities before writing settings:
  • Use current_user_can(‘manage_options’) or a capability appropriate for the action.
• Use nonces for state-changing requests initiated from the admin UI:
  • Verify the nonce server-side using check_admin_referer or wp_verify_nonce where suitable.
• REST API: register routes with proper permission_callback:
  • Do not register REST routes with permission_callback set to ‘__return_true’ or left unset.
• Admin-ajax: ensure actions are only callable by authenticated users when performing privileged operations. Use the admin_init hook and use check_ajax_referer where appropriate.
• Sanitize and validate all inputs before storing:
  • Use sanitize_text_field, esc_url_raw, wp_kses_post or custom sanitizers depending on expected content.
• Avoid storing sensitive tokens in plain text without access controls.
• Logging and auditing: write audit entries when settings change, including actor identity and origin.
• Fallback defaults: ensure default safe settings if inputs are malformed.
• Unit tests and security tests: include tests that validate that unauthorized users cannot update settings.

If you maintain plugins, review all endpoints and Ajax actions, and treat any change as potentially high-risk until proven otherwise.

---

9) Incident response: what to do if you believe you were exploited

If your site shows signs of unauthorized settings changes, follow a conservative forensic-first approach:

1. সাইটটি আলাদা করুন
   • Put the site into maintenance mode, suspend public access, or limit access to a small set of IPs to prevent further changes.
2. Snapshot everything
   • Take immediate snapshots/backups of files, database, and server logs for later analysis.
3. শংসাপত্রগুলি ঘোরান
   • Reset admin accounts, API keys, and plugin-specific tokens (after taking snapshots).
4. Remove the vulnerable plugin
   • Deactivate and delete the plugin if you don’t need it. If you must keep it, apply virtual patches and hardening.
5. Clean or restore
   • If you have a clean backup from before the suspected compromise, consider restoring from that backup after ensuring the attack vector is removed.
   • If you must clean in place, search for rogue admin users, malicious files, and injected content. Cleaning is riskier and should be done by experienced responders.
6. Scan and validate
   • Run a full malware scan, check scheduled tasks (cron), plugins, and themes for unauthorized changes.
7. Report and coordinate
   • Notify your host if you need server-level scans and assistance.
   • If the site stores user data or is part of a larger environment, comply with contractual or legal obligations for disclosure.
8. Learn and prevent
   • Implement monitoring, WAF rules, scheduled backups, and secure coding practices to reduce future risk.

If you are unsure how to proceed, engage a professional WordPress incident response firm.

---

10) How WP-Firewall helps (free protection + upgrade options)

Protect your WordPress site right now — start with WP-Firewall Basic (Free)

We know how fast automated scanners and mass-exploitation bots move after a vulnerability is announced. To help site owners stay ahead, WP-Firewall provides a free protection tier that includes essential mitigations you need immediately:

• বেসিক (বিনামূল্যে)
  • Managed firewall and WAF
  • সীমাহীন ব্যান্ডউইথ সুরক্ষা
  • Malware scanning
  • Mitigation of OWASP Top 10 risks

If you want additional automated cleanup and customization:

• Standard — $50/year
  • Includes everything in Basic, plus automatic malware removal and up to 20 IPs for blacklist/whitelist management.
• Pro — $299/year
  • Includes automatic vulnerability virtual patching, monthly security reports, and premium support and services.

Sign up for the free plan and get an immediate layer of protection while you evaluate long-term remediation: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(We apply targeted virtual patches and WAF rules for critical vulnerabilities like unauthenticated settings-update flaws — this can block exploit attempts even before an official plugin patch is released.)

---

Practical checklist for site owners — what to do now

1. Inventory
   • Find all sites using Add Multiple Marker and identify those running version <= 1.2.
2. কন্টেনমেন্ট
   • If the plugin is not required, deactivate and delete it now.
   • If you must keep it, restrict access to admin endpoints and apply WAF rules.
3. Backups
   • Take immediate file and DB backups and copy server logs for forensic purposes.
4. মনিটর
   • Watch for unexpected option updates, sudden admin logins, or new content changes.
5. শক্ত করা
   • Enforce strong admin passwords and two-factor authentication on admin accounts.
   • Disable plugin and theme editors in wp-admin with সংজ্ঞায়িত করুন ('DISALLOW_FILE_EDIT', সত্য);
   • Consider HTTP Basic for wp-admin and limit access by IP where operationally possible.
6. WAF
   • Deploy targeted WAF rules that block unauthenticated POSTs to any endpoints used for settings updates for the affected plugin.
7. Rotate secrets
   • If any plugin or site-level keys or secrets may have been exposed, rotate them.
8. যোগাযোগ
   • If you suspect exploitation, engage your hosting provider and consider professional incident responders.

---

For hosts and managed WordPress platforms

If you are a hosting provider or manage many WordPress sites, this class of vulnerability is a prime candidate for rapid virtual-patching across customer sites:

• Identify customers using the vulnerable plugin and notify them with clear remediation steps.
• Apply targeted blocking at the HTTP layer for requests that attempt to modify plugin settings without valid admin context.
• Provide an opt-in automatic mitigation that protects customers until a vendor patch is released.
• Maintain transparent communications and incident tracking for affected customers.

---

For developers and security reviewers

When auditing WordPress plugins, pay special attention to:

• All code paths that call update_option, update_site_option, add_option, delete_option, or otherwise modify persistent state.
• অ্যাডমিন-ajax.php handlers and REST API routes — make sure proper permission callbacks or nonce checks are enforced.
• Unit tests and integration tests that simulate unauthenticated access to sensitive endpoints.

A simple but effective audit step: search the codebase for update_option and trace upstream to find all user inputs that can reach that call. Ensure each path is authenticated and authorized.

---

সমাপনী ভাবনা

Broken access control is a recurring theme in WordPress plugin vulnerabilities because plugins frequently expose admin functionality and may forget the necessary authorization checks. An unauthenticated settings-update weakness like the one reported for the Add Multiple Marker plugin is a strong reminder that even “non-critical” configuration endpoints can be footholds for broader compromise.

If you manage WordPress sites, take a proactive approach:

• Maintain up-to-date inventories of installed plugins.
• Harden admin entry points and enforce least-privilege.
• Use a managed WAF or virtual-patching service to buy time while vendors produce fixes.
• Regularly audit plugins and keep communications open with your hosting provider or security partner.

If you need fast, managed protection, WP-Firewall’s Basic (Free) plan provides the essential WAF, malware scanning, and core protections to help block exploitation attempts while you take the remediation steps above. Start protecting your site now: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Appendix: Useful resources

• CVE-2025-11999 (reference): CVE entry for this issue (search by CVE ID in public databases)
• WordPress hardening guide: review official hardening recommendations and apply them consistently.
• Dev checklist: capability checks, nonces, sanitized inputs, permission_callback for REST routes, audit logs.

---

If you want, we can:

• Provide an audit template you can use to scan your site inventory for this vulnerability.
• Draft a targeted WAF rule set tailored to the plugin’s exposed endpoints (safe, non-destructive, and tuned to minimize false positives).
• Walk you through the steps to lock down wp-admin for a specific site or environment.

Contact the WP-Firewall support team or use the free plan signup to get immediate automated protections in place.