What happened (high level)

A stored XSS vulnerability was found in the Morkva UA Shipping plugin. The plugin accepted input for a “Weight, kg” field and did not properly validate or escape that input before storing it in the database and rendering it later in admin or frontend views. Because the data was stored and later rendered without adequate sanitization, a malicious administrator could inject script content that executes in the context of other administrators viewing the affected pages.

Key points:

• Attacker prerequisite: an authenticated Administrator account (or another role with capability to edit the affected field).
• Vulnerability type: Stored (persistent) XSS.
• Impact: Execution of attacker-supplied JavaScript in admin pages or frontend pages where the stored field is rendered.
• Fix: Plugin author released version 1.7.10 addressing the input validation and escaping issues.

Why stored XSS matters even for “admin-only” vectors

Administrators are trusted, but that trust is often abused or broken. Consider:

• Admin accounts are commonly compromised via phishing, credential reuse, weak MFA, or stolen sessions.
• Malicious or compromised admins can install backdoors, modify options, install plugins, and exfiltrate secrets.
• Stored XSS persists and executes whenever the infected field is viewed, automatically targeting other privileged users.
• XSS can be used to obtain REST API tokens, change configurations, or install persistent malware.

Even when an issue is “admin-only,” the downstream risk is material and deserves attention.

Technical analysis — what went wrong

Root cause summary:

• The plugin accepted a value for a numeric field (weight in kg) but did not validate the input as numeric.
• User-supplied HTML/JS was stored and later echoed into pages without proper escaping or filtering.

Typical faulty pattern (simplified, illustrative):

Correct approach:

• Validate the field as a number on input (float or int as appropriate).
• Cast or sanitize inputs (e.g., floatval, preg_match for numeric pattern).
• Escape output with appropriate functions (esc_html, esc_attr, number_format) before echoing into HTML context.

Demonstration (safe and educational)

To illustrate without providing an exploitable recipe: if an admin enters a “weight” value containing HTML tags, and the plugin later echoes that value with echo $value; instead of echo esc_html( $value );, the browser will parse and execute the tags.

Example of an obviously malicious string (for understanding only):

Example of correct handling (sanitization + escaping):

Restricting the underlying type to numeric values and escaping on output closes the stored XSS avenue.

Exploitation scenarios (high level)

An administrator who controls an account (or who tricks an admin into pasting malicious content) might:

• Inject JavaScript into the weight field that targets other admins to steal cookies or perform actions via admin AJAX endpoints.
• Inject UI elements (fake notices, forms) to capture credentials or social-engineer administrators.
• Create persistence by writing malicious content to other options or by installing a backdoored plugin if the account has install permissions.

Because the injection persists in the database, any admin viewing the affected page may execute the script automatically.

Risk assessment

• Attack complexity: Low (requires admin privileges).
• Privilege required: Administrator (or equivalent capability).
• Impact: Potentially high if XSS is used to obtain session cookies, perform admin API calls, or install persistent backdoors.
• Exploitability: Not exploitable by anonymous users; secondary paths (compromised lower-privilege accounts or social engineering) can lead to abuse.

Immediate actions for site owners and administrators

If you run Morkva UA Shipping and are on version ≤ 1.7.9:

1. Update immediately
   • Upgrade the plugin to 1.7.10 or later — this is the single best remediation.
2. If you cannot update right away, temporary options
   • Disable the plugin until you can upgrade.
   • Restrict access to admin pages to trusted IPs where feasible.
   • Audit admin accounts: remove unused accounts and enforce unique strong passwords.
   • Enforce multi-factor authentication (MFA) for all admin-level accounts.
3. Scan and clean
   • Search the database for stored script tags and suspicious inline attributes (e.g.,
   • If you find suspicious entries, review and remove or neutralize payloads, and reset credentials for affected users.
   • Perform a full site malware scan and integrity check of plugin/theme files.
4. Rotate secrets
   • Force password resets for all admin users, or at minimum reset sessions for accounts that could be exposed.
   • Rotate API keys/tokens used by the site if there’s any suspicion of compromise.
5. Monitor logs
   • Review access logs and admin activity logs for suspicious activity around injection times (new plugin installs, updates, changes to options, large admin POSTs).

Detection and hunting (practical queries and commands)

Safe methods to find potential stored XSS instances introduced via the weight field or elsewhere.

WP-CLI examples:

# Search wp_options for 
			
				
			
					

							
			
			
			





		

		
					
				 
 
   
 
  
 
 Review My Order
 0 
 
 
  
 
 
  
 
 
 
 Subtotal
 
Taxes & shipping calculated at checkout
 
 
  
 
 
 
   Checkout