CVE-2023-42768

7.2 HIGH

📋 TL;DR

This vulnerability allows non-admin users who previously had admin privileges to retain access to iControl REST admin resources even after their role has been reverted. It affects BIG-IP systems where role changes have occurred via mixed management methods. The issue impacts organizations using F5 BIG-IP with role-based access control.

💻 Affected Systems

Products:
  • F5 BIG-IP
Versions: Multiple versions (see F5 advisory for specifics)
Operating Systems: BIG-IP TMOS
Default Config Vulnerable: ✅ No
Notes: Only affects systems where non-admin users have been assigned admin roles via iControl REST PUT and later reverted via other methods. Systems using consistent role management methods are not affected.

📦 What is this software?

⚠️ Risk & Real-World Impact

🔴

Worst Case

A previously privileged non-admin user could perform administrative actions, modify configurations, access sensitive data, or disrupt network services through the retained iControl REST access.

🟠

Likely Case

Formerly privileged users could unintentionally or intentionally access administrative functions they should no longer have, potentially leading to configuration changes or data exposure.

🟢

If Mitigated

With proper access monitoring and role verification procedures, the impact is limited to potential temporary access until detected and corrected.

🌐 Internet-Facing: MEDIUM
🏢 Internal Only: HIGH

🎯 Exploit Status

Public PoC: ✅ No
Weaponized: UNKNOWN
Unauthenticated Exploit: ✅ No
Complexity: LOW

Exploitation requires authenticated access and specific role change history. The vulnerability is in role persistence logic rather than a traditional exploit chain.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: Refer to F5 advisory K26910459 for version-specific fixes

Vendor Advisory: https://my.f5.com/manage/s/article/K26910459

Restart Required: Yes

Instructions:

1. Review F5 advisory K26910459 for your specific BIG-IP version. 2. Apply the recommended fix version. 3. Restart BIG-IP services as required. 4. Verify role assignments are consistent across all management interfaces.

🔧 Temporary Workarounds

Role Consistency Enforcement

all

Ensure role changes are performed consistently using a single management method (either iControl REST or Configuration Utility/tmsh, not both)

Access Review and Cleanup

linux

Review all user roles and remove any lingering admin permissions from non-admin users

tmsh list auth user
tmsh modify auth user <username> partition-access replace-all-with { <correct-permissions> }

🧯 If You Can't Patch

  • Audit all user role assignments and ensure no users have inconsistent permissions across management interfaces
  • Implement strict monitoring of iControl REST access logs for unauthorized admin resource access

🔍 How to Verify

Check if Vulnerable:

Check if any non-admin users have been assigned admin roles via iControl REST PUT and later reverted via other methods. Review role change history and current permissions.

Check Version:

tmsh show sys version

Verify Fix Applied:

After patching, test role changes using mixed methods and verify permissions are correctly revoked. Check that previously affected users no longer have admin access via iControl REST.

📡 Detection & Monitoring

Log Indicators:

  • iControl REST admin resource access by non-admin users
  • Role modification events using different management methods
  • Unexpected administrative actions from non-admin accounts

Network Indicators:

  • iControl REST API calls to admin endpoints from non-privileged user contexts

SIEM Query:

source="bigip" AND (event_type="role_change" OR api_endpoint="/mgmt/tm/*") AND user_role="non-admin"

🔗 References

📤 Share & Export