This is a forged signature on an internal routing slip, not a master key to the building
CVE-2026-28761 is a classic CSRF issue in Fujitsu Japan Musetheque V4 Information Disclosure for IPKNOWLEDGE affecting V4L1 rev2203.0 and earlier. If a victim is already logged in and then loads attacker-controlled HTML, the browser can replay authenticated requests into the application and trigger unintended actions. JVN says the result is that "unexpected operations may be done"; the fixed release called out publicly is V4L1 rev2603.1, while Fujitsu also says corrective updates are provided to customers individually via distributors.
The vendor's 8.1/HIGH score is technically understandable in a lab because CSRF can inherit the victim's privileges and may touch confidentiality and integrity. In real enterprise conditions, though, this is post-session abuse with mandatory user interaction, on a niche on-prem product with a small reachable population and no confirmed exploitation, no KEV listing, and very low EPSS. That combination is downward pressure all the way to MEDIUM.
4 steps from start to impact.
Find a reachable Musetheque admin user
- The organization actually uses Musetheque V4 Information Disclosure for IPKNOWLEDGE
- A privileged or semi-privileged user has an active authenticated session
- The victim can be reached by email, chat, or web content
- This is a niche Fujitsu Japan product with a comparatively small deployment base
- The product is marketed as on-prem and customer-specific, which shrinks exposed population
- If the admin interface is VPN-restricted or intranet-only, random internet attackers lose easy reach
Deliver a browser-based CSRF lure
- The victim must load attacker-controlled content
- The target request must be accepted cross-site by the browser and application
- Email gateways, web filtering, user awareness, and browser anti-tracking controls reduce lure success
- Modern cookies with
SameSite=LaxorStrictcan break some cross-site request patterns - If the action requires anti-automation fields, one-time tokens, or re-auth, the attack dies here
Ride the victim's session cookies
- The application does not validate CSRF tokens consistently
- Origin or Referer checks are absent, weak, or bypassable
- The vulnerable workflow is reachable with a single request
- Per-request CSRF tokens stop this cold
- Origin/Referer enforcement and custom non-cookie auth headers add meaningful resistance
- If the sensitive function is not directly callable or needs multi-step workflows, the exploit becomes brittle
Trigger unintended application actions
- The victim account has privileges over the targeted function
- The chosen action actually changes data or reveals protected information
- Blast radius is capped at the victim account and the specific function exposed
- No evidence in the public advisory shows code execution, auth bypass, or tenant-wide compromise
- The product brochure states this SKU is focused on information publication and notes no data-editing function, suggesting some workflows may be narrower than the CVSS implies
The supporting signals.
| In-the-wild status | No confirmed exploitation found in the reviewed public sources. OpenCVE shows KEV: No and CISA ADP marks exploitation as none for this record. |
|---|---|
| Proof-of-concept availability | No public repo or turnkey exploit module located in GitHub/web searches during this review. Realistically, a PoC would just be a small HTML form built from a captured request in Burp Suite. |
| EPSS | 0.00018 per the provided intel, which is extremely low in absolute terms. I did not independently confirm the percentile from a primary source during this review. |
| KEV status | Not listed in CISA's Known Exploited Vulnerabilities catalog as of this review; disclosed 2026-05-15. |
| CVSS vector reality check | AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N overstates field urgency because UI:R plus a required authenticated session turns this into a lure-and-session problem, not direct pre-auth compromise. |
| Affected versions | Musetheque V4 Information Disclosure for IPKNOWLEDGE V4L1 rev2203.0 and earlier. |
| Fixed version / patch channel | JVN names V4L1 rev2603.1 as fixed. Fujitsu's vendor statement also says the corrective update is provided individually to affected customers via distributors, so expect patch acquisition to be customer-specific. |
| Deployment and exposure context | Fujitsu markets this SKU as on-premises and focused on public-information disclosure/search tied to IPKNOWLEDGE. That matters: the reachable install base is likely small and environment-specific, not mass internet software. |
| Internet exposure signal | No reliable public fingerprint found in common search results for Shodan/Censys-style discovery during this review. That does not prove no exposure; it means external census-based targeting is not straightforward. |
| Disclosure and credits | Disclosed 2026-05-15 through JVN/JPCERT. Credit goes to Nozomi Iimura and Sho Odagiri of GMO Cybersecurity by Ierae, Inc. |
noisgate verdict.
The single biggest downgrade factor is that this bug requires a logged-in victim to be tricked into loading attacker content; there is no direct unauthenticated exploit path into the server. Add the product's niche, on-prem deployment profile and the absence of exploitation evidence, and this stops looking like a vendor-HIGH fleet emergency.
Why this verdict
- Requires victim session: the attacker does not get value unless a currently authenticated user loads attacker-controlled content. That is a compounded prerequisite, not a direct service compromise.
- Niche exposure population: Musetheque/IPKNOWLEDGE is a specialized Fujitsu Japan product, marketed as on-prem and historically deployed in a relatively small customer set. This sharply limits opportunistic internet-scale abuse.
- Controls should break the chain: secure email gateways, web filtering,
SameSitecookies, CSRF tokens, Origin/Referer validation, VPN-only admin access, and basic application logging all put friction in front of exploitation.
Why not higher?
There is no evidence here of pre-auth remote compromise, code execution, or wormable behavior. The attacker needs browser-mediated execution, an authenticated victim, a working lure, and a vulnerable endpoint that accepts a forged request; every one of those prerequisites narrows the real blast radius.
Why not lower?
It is still a remotely triggerable web flaw that can piggyback a real user's privileges with minimal exploit development. If your admin users browse the internet while logged in to this application, the attack path is absolutely practical enough to warrant planned remediation rather than backlog oblivion.
What to do — in priority order.
- Put the admin surface behind VPN — Restrict administrator and curator interfaces to trusted network paths only. For a MEDIUM verdict there is no formal mitigation SLA, but this is a strong risk reducer to apply during normal hardening because it removes the easiest path for random internet lures to reach authenticated users.
- Enforce
SameSiteand secure cookie settings — Where the application stack allows it, set session cookies toSameSite=LaxorStrict, plusSecureandHttpOnly. This will not fix every CSRF case, but it meaningfully reduces ambient cross-site request replay and should be deployed as part of standard web-app hygiene. - Validate Origin and Referer on state-changing routes — At the web tier or reverse proxy, reject unsafe methods lacking trusted
Origin/Refererheaders for administrative actions. This is a practical temporary shield while you obtain and validate the vendor's customer-specific corrective update. - Segregate admin browsing — Use separate admin workstations or browser profiles for Musetheque administration so staff are not casually visiting external sites with a live session. This lowers the chance of the exact lure condition the vulnerability depends on.
- Review application audit logs — Pull action logs for the affected users and look for unexpected configuration or publication changes during active session windows. This is especially useful because successful CSRF often looks like a legitimate user action unless you correlate surrounding web activity.
- A perimeter WAF alone does not solve this; the forged request often looks like a normal in-policy action from a valid session.
- MFA at login helps account compromise, not session-riding after login. Once the browser has the session cookie, MFA has already done its job and is no longer in the request path.
- Endpoint AV on the server is mostly irrelevant here because the exploit is a browser-to-web-app logic flaw, not malware execution on the host.
Crowdsourced verification payload.
Run this from an auditor workstation or the target host with Python 3. It supports either a local install path or the web app URL: python3 check_musetheque_cve_2026_28761.py --path /opt/musetheque or python3 check_musetheque_cve_2026_28761.py --url https://portal.example.local/. No admin privileges are required unless the install directory is access-restricted.
#!/usr/bin/env python3
# check_musetheque_cve_2026_28761.py
# Purpose: best-effort version check for CVE-2026-28761
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/runtime error
import argparse
import os
import re
import sys
from urllib.request import Request, urlopen
from urllib.error import URLError, HTTPError
VULN_MAX = (2203, 0) # rev2203.0 and earlier vulnerable
PATCH_MIN = (2603, 1) # rev2603.1 fixed per JVN
VERSION_RE = re.compile(r'rev\s*(\d{4})\.(\d+)', re.IGNORECASE)
TARGET_HINTS = [
'Musetheque',
'IPKNOWLEDGE',
'Musetheque V4',
'情報公開 for IPKNOWLEDGE'
]
def parse_rev(text):
matches = VERSION_RE.findall(text or '')
versions = []
for major, minor in matches:
try:
versions.append((int(major), int(minor)))
except ValueError:
pass
return versions
def classify(versions):
if not versions:
return None
# If any explicitly patched version is present, treat as patched.
for v in versions:
if v >= PATCH_MIN:
return 'PATCHED'
# Otherwise if any vulnerable version is present, treat as vulnerable.
for v in versions:
if v <= VULN_MAX:
return 'VULNERABLE'
return 'UNKNOWN'
def scan_file(path):
try:
if os.path.getsize(path) > 5 * 1024 * 1024:
return []
with open(path, 'rb') as f:
data = f.read()
text = data.decode('utf-8', errors='ignore')
return parse_rev(text)
except Exception:
return []
def scan_path(root):
found_versions = []
hints_seen = False
for dirpath, _, filenames in os.walk(root):
for name in filenames:
full = os.path.join(dirpath, name)
lowered = name.lower()
if any(k.lower() in lowered for k in ['musetheque', 'ipknowledge', 'version', 'about', 'manifest', 'readme', 'release']):
hints_seen = True
versions = scan_file(full)
if versions:
found_versions.extend(versions)
hints_seen = True
return hints_seen, found_versions
def fetch_url(url):
req = Request(url, headers={'User-Agent': 'Mozilla/5.0 noisgate-version-check'})
with urlopen(req, timeout=10) as resp:
raw = resp.read(1024 * 1024)
return raw.decode('utf-8', errors='ignore')
def scan_url(base_url):
candidates = [
base_url,
base_url.rstrip('/') + '/login',
base_url.rstrip('/') + '/index.html',
base_url.rstrip('/') + '/about',
]
versions = []
target_hints = False
for u in candidates:
try:
text = fetch_url(u)
if any(h in text for h in TARGET_HINTS):
target_hints = True
versions.extend(parse_rev(text))
except (URLError, HTTPError, TimeoutError, ValueError):
continue
return target_hints, versions
def print_result(result, detail=''):
if detail:
print(f'{result}: {detail}')
else:
print(result)
if result == 'PATCHED':
sys.exit(0)
if result == 'VULNERABLE':
sys.exit(1)
if result == 'UNKNOWN':
sys.exit(2)
sys.exit(3)
def main():
parser = argparse.ArgumentParser(description='Best-effort checker for CVE-2026-28761 in Musetheque V4 Information Disclosure for IPKNOWLEDGE')
group = parser.add_mutually_exclusive_group(required=True)
group.add_argument('--path', help='Local installation directory to scan')
group.add_argument('--url', help='Base URL of the web application')
args = parser.parse_args()
if args.path:
if not os.path.isdir(args.path):
print_result('UNKNOWN', f'path not found or not a directory: {args.path}')
hints_seen, versions = scan_path(args.path)
result = classify(versions)
if result:
vers = ', '.join([f'rev{a}.{b}' for a, b in sorted(set(versions))])
print_result(result, f'local version markers found: {vers}')
if hints_seen:
print_result('UNKNOWN', 'installation artifacts found but no decisive version string was located')
print_result('UNKNOWN', 'no Musetheque/IPKNOWLEDGE-specific artifacts or version markers were located')
if args.url:
hints_seen, versions = scan_url(args.url)
result = classify(versions)
if result:
vers = ', '.join([f'rev{a}.{b}' for a, b in sorted(set(versions))])
print_result(result, f'web-exposed version markers found: {vers}')
if hints_seen:
print_result('UNKNOWN', 'target appears to be Musetheque/IPKNOWLEDGE but no decisive version string was exposed')
print_result('UNKNOWN', 'could not confirm target identity or version from HTTP responses')
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- NVD CVE-2026-28761
- JVN English advisory JVN#69128376
- JVN vendor statement from Fujitsu Japan Limited
- OpenCVE record for CVE-2026-28761
- Fujitsu Musetheque v4 press release
- Fujitsu Musetheque V4 Information Disclosure for IPKNOWLEDGE brochure
- CISA Known Exploited Vulnerabilities catalog
- FIRST EPSS documentation
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.