Missing Function Level Access Control

Tenable plugin 121039 is a generic web-application authorization test, not a product-specific CVE. It looks for cases where a remote web app exposes privileged functionality to a low-privileged or even unauthenticated user because the server fails to enforce authorization on the function itself. Tenable published this plugin on 2019-01-09 and currently scores it as Critical / CVSS 9.1; the scan only runs when generic web application tests are enabled, and the plugin documentation shows it depends on web-app test settings rather than any affected software version range.

The vendor score is too aggressive for patch prioritization at enterprise scale. Broken access control is absolutely dangerous when confirmed, but this plugin is a category-level DAST signal with heavy real-world friction: it often requires hidden endpoint discovery, role-context testing, and manual confirmation that a privileged action actually succeeded. In other words, the bug class is severe; the *scanner finding* is not automatically a Critical patch event.

Why this verdict

• Vendor baseline is inflated for patch ops: Tenable's 9.1 assumes PR:N/UI:N, but real exploitation commonly requires route discovery, a valid low-priv session, or a role boundary to abuse.
• Reachable population is narrow: this is only exploitable on the specific application paths where authorization is missing; it is not a fleet-wide software defect with a universal exploit.
• Modern controls add friction: authenticated scanning gaps, MFA, anti-automation, WAFs, CSRF/workflow state, and tenant segmentation frequently break the clean exploit path implied by CVSS.

Why not higher?

I am not calling this HIGH or CRITICAL because the finding is not a vendor-confirmed product vulnerability with known affected versions, known exploit code, or broad exploitation telemetry. In many environments it is a candidate logic flaw that still needs a human to prove an actual unauthorized action succeeded and to measure blast radius.

Why not lower?

I am not pushing this to LOW because broken access control remains one of the most damaging web-app classes when validated. If the privileged function exposes sensitive data, admin actions, or cross-tenant impact, the practical business risk is real even without a CVE.

1. Validate the route manually — Use an auditor workstation with Burp Suite, OWASP ZAP, or curl to confirm whether the exact endpoint found by Tenable returns a meaningful privileged action to an unauthenticated or low-privileged session. Because this is a MEDIUM verdict, there is no mitigation SLA; validate before mobilizing engineering, then place confirmed issues into the remediation queue within 365 days unless business impact justifies faster handling.
2. Enforce server-side authorization centrally — Move authorization checks into middleware, route guards, controller decorators, or policy engines rather than relying on hidden UI elements or client-side role checks. For confirmed findings, ship that control as the durable fix within the 365-day remediation window for MEDIUM, sooner if the route is internet-facing and touches admin or regulated data.
3. Constrain sensitive endpoints at the edge — Where practical, put admin routes behind SSO groups, VPN, IP allowlists, or API gateway policy so the reachable population shrinks even if application logic is imperfect. This is a useful compensating control while the application team works the code fix inside the 365-day remediation window.
4. Log authorization failures and privileged actions — Instrument the app and gateway to record 401/403, role mismatches, admin route access, export actions, and state-changing privileged API calls. Detection does not fix the bug, but it reduces dwell time and gives you evidence if a confirmed finding is probed before code remediation lands.

Run this from an auditor workstation against the affected application after you identify the suspected privileged route from the Tenable output. Invoke it as python verify_mflac.py https://app.example.com /admin/users --cookie "session=LOWPRIVCOOKIE" --allow-text "User Administration"; no local admin rights are needed, but you do need a known low-priv session if the route is authenticated.

#!/usr/bin/env python3
# verify_mflac.py
# Purpose: sanity-check a suspected Missing Function Level Access Control finding.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/network error

import argparse
import sys
import requests
from urllib.parse import urljoin

DENY_CODES = {401, 403}
REDIRECT_DENY_HINTS = ('login', 'signin', 'auth')


def build_session(cookie_header: str, header_list):
    s = requests.Session()
    if cookie_header:
        s.headers['Cookie'] = cookie_header
    for item in header_list:
        if ':' not in item:
            continue
        k, v = item.split(':', 1)
        s.headers[k.strip()] = v.strip()
    s.headers.setdefault('User-Agent', 'noisgate-mflac-check/1.0')
    return s


def is_redirect_to_login(resp):
    if not resp.history and resp.status_code not in (301, 302, 303, 307, 308):
        return False
    loc = resp.url.lower()
    return any(hint in loc for hint in REDIRECT_DENY_HINTS)


def main():
    parser = argparse.ArgumentParser(description='Verify suspected Missing Function Level Access Control')
    parser.add_argument('base_url', help='Base URL, e.g. https://app.example.com')
    parser.add_argument('path', help='Suspected privileged path, e.g. /admin/users')
    parser.add_argument('--cookie', default='', help='Cookie header for low-priv session, e.g. "session=abc"')
    parser.add_argument('--header', action='append', default=[], help='Additional header, repeatable, e.g. "X-CSRF-Token: abc"')
    parser.add_argument('--method', default='GET', choices=['GET', 'POST', 'HEAD'], help='HTTP method to use')
    parser.add_argument('--data', default='', help='Optional POST body')
    parser.add_argument('--allow-text', default='', help='Text that indicates the privileged page/action really loaded')
    parser.add_argument('--timeout', type=int, default=15, help='HTTP timeout in seconds')
    args = parser.parse_args()

    url = urljoin(args.base_url.rstrip('/') + '/', args.path.lstrip('/'))
    session = build_session(args.cookie, args.header)

    try:
        if args.method == 'GET':
            resp = session.get(url, timeout=args.timeout, allow_redirects=True, verify=True)
        elif args.method == 'HEAD':
            resp = session.head(url, timeout=args.timeout, allow_redirects=True, verify=True)
        else:
            resp = session.post(url, data=args.data, timeout=args.timeout, allow_redirects=True, verify=True)
    except requests.RequestException as exc:
        print(f'UNKNOWN - request failed: {exc}')
        sys.exit(3)

    body = resp.text[:200000] if hasattr(resp, 'text') else ''

    if resp.status_code in DENY_CODES or is_redirect_to_login(resp):
        print(f'PATCHED - access denied ({resp.status_code}) for {url}')
        sys.exit(0)

    if 200 <= resp.status_code < 300:
        if args.allow_text:
            if args.allow_text.lower() in body.lower():
                print(f'VULNERABLE - privileged content marker matched on {url} ({resp.status_code})')
                sys.exit(1)
            else:
                print(f'UNKNOWN - got {resp.status_code} but privileged content marker not found on {url}')
                sys.exit(2)
        else:
            print(f'UNKNOWN - got {resp.status_code} on {url}; provide --allow-text to confirm real privileged access')
            sys.exit(2)

    if resp.status_code in (301, 302, 303, 307, 308):
        print(f'UNKNOWN - redirect observed ({resp.status_code}) to {resp.url}')
        sys.exit(2)

    print(f'UNKNOWN - unexpected status {resp.status_code} for {url}')
    sys.exit(2)


if __name__ == '__main__':
    main()

Sources

1. Tenable Plugin 121039
2. Tenable Nessus Web Application Scanning
3. Tenable Nessus User Guide PDF - Generic web application tests
4. OWASP Top 10 A01 Broken Access Control
5. OWASP WSTG - Testing for Bypassing Authorization Schema
6. MITRE CWE-862 Missing Authorization
7. PortSwigger Web Security Academy - Access control vulnerabilities