CWE-434

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-0547",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-01-02T14:15:38.067840Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-01-05T21:50:05.776Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "cpes": [
            "cpe:2.3:a:phpgurukul:online_course_registration:*:*:*:*:*:*:*:*"
          ],
          "modules": [
            "Student Registration Page"
          ],
          "product": "Online Course Registration",
          "vendor": "PHPGurukul",
          "versions": [
            {
              "status": "affected",
              "version": "3.0"
            },
            {
              "status": "affected",
              "version": "3.1"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "hackerfactory (VulDB User)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "A vulnerability was found in PHPGurukul Online Course Registration up to 3.1. This issue affects some unknown processing of the file /admin/edit-student-profile.php of the component Student Registration Page. The manipulation of the argument photo results in unrestricted upload. The attack may be launched remotely. The exploit has been made public and could be used."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "baseScore": 5.3,
            "baseSeverity": "MEDIUM",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P",
            "version": "4.0"
          }
        },
        {
          "cvssV3_1": {
            "baseScore": 6.3,
            "baseSeverity": "MEDIUM",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L/E:P/RL:X/RC:R",
            "version": "3.1"
          }
        },
        {
          "cvssV3_0": {
            "baseScore": 6.3,
            "baseSeverity": "MEDIUM",
            "vectorString": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L/E:P/RL:X/RC:R",
            "version": "3.0"
          }
        },
        {
          "cvssV2_0": {
            "baseScore": 6.5,
            "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P/E:POC/RL:ND/RC:UR",
            "version": "2.0"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-434",
              "description": "Unrestricted Upload",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-284",
              "description": "Improper Access Controls",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-02-23T08:08:25.076Z",
        "orgId": "1af790b2-7ee1-4545-860a-a788eba489b5",
        "shortName": "VulDB"
      },
      "references": [
        {
          "name": "VDB-339355 | PHPGurukul Online Course Registration Student Registration edit-student-profile.php unrestricted upload",
          "tags": [
            "vdb-entry",
            "technical-description"
          ],
          "url": "https://vuldb.com/?id.339355"
        },
        {
          "name": "VDB-339355 | CTI Indicators (IOB, IOC, TTP, IOA)",
          "tags": [
            "signature",
            "permissions-required"
          ],
          "url": "https://vuldb.com/?ctiid.339355"
        },
        {
          "name": "Submit #728988 | PHPGurukul Online Course Registration v3.1 Cross Site Scripting",
          "tags": [
            "third-party-advisory"
          ],
          "url": "https://vuldb.com/?submit.728988"
        },
        {
          "tags": [
            "exploit"
          ],
          "url": "https://github.com/rsecroot/Online-Course-Registration/blob/main/Cross%20Site%20Scripting.md"
        },
        {
          "tags": [
            "product"
          ],
          "url": "https://phpgurukul.com/"
        }
      ],
      "tags": [
        "x_freeware"
      ],
      "timeline": [
        {
          "lang": "en",
          "time": "2026-01-01T00:00:00.000Z",
          "value": "Advisory disclosed"
        },
        {
          "lang": "en",
          "time": "2026-01-01T01:00:00.000Z",
          "value": "VulDB entry created"
        },
        {
          "lang": "en",
          "time": "2026-01-15T07:34:57.000Z",
          "value": "VulDB entry last update"
        }
      ],
      "title": "PHPGurukul Online Course Registration Student Registration edit-student-profile.php unrestricted upload"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "1af790b2-7ee1-4545-860a-a788eba489b5",
    "assignerShortName": "VulDB",
    "cveId": "CVE-2026-0547",
    "datePublished": "2026-01-02T09:32:07.601Z",
    "dateReserved": "2026-01-01T13:21:45.563Z",
    "dateUpdated": "2026-02-23T08:08:25.076Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "Crystal Server",
          "vendor": "Nuuo",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "disclosure via Fulldisclosure"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "0day Rubbish Research Team is publicly disclosing a vulnerability in NUUO\nCrystal Server 3.19.0.85, the video management and NVR server software from\nNUUO Inc. of Taipei (Taiwan), distributed as the Crystal virtual-machine\nappliance: an Ubuntu-based OVA whose web tier is a lighttpd server fronting\na PHP application, with .php requests dispatched to /usr/bin/php-cgi through\nlighttpd\u0027s fastcgi mapping. The product sits in the management plane of\nphysical-security and critical-infrastructure video deployments, brokering\ncamera registration, recorder channels and the stored management credentials\nof the surveillance estate.\n\nType and root cause. Inside the web root recovered from the appliance disk\nimage, upload.php is three lines long, and the brevity is the finding: it\nechoes the client-supplied filename and calls copy() with a destination\ntaken from that same client-supplied filename. There is no session include,\nno login check, no extension filter, no MIME check, no path restriction and\nno storage directory of the product\u0027s own choosing. The web server\nconfiguration recovered from the same disk image loads no authentication\nmodule at all, because this product\u0027s architecture delegates authentication\nto each PHP file individually, and upload.php is one of the files that\nnever asks. Three omissions stack into one chain, each independently\nsufficient to make the write dangerous: missing authentication for a\ncritical function (CWE-306 primary), an upload accepted without type\nrestriction into an executable mapping (CWE-434 co-equal), and external\ncontrol of the destination file name or path (CWE-73 contributing).\n\nThe chain. An anonymous client on any network that can reach the management\ninterface posts a multipart body carrying a PHP payload whose disposition\nfilename is the destination of the write. copy() writes the file under the\nattacker-chosen name into the served document root /NU20/web/, the HTTPS\nlistener of the recovered configuration binding :443 across addresses with\nno restriction. One fetch of the written path then hands the file to the\nproduct\u0027s own fastcgi mapping, and the chosen PHP executes in the product\u0027s\nweb service context. Two requests, no credential at any point, no memory\ncorruption, no deserialisation gadget, no default credential and no action\nby any user of the product. The write and the execution are decoupled in\ntime, which makes the write primitive independently useful: served pages\ncan be replaced, configuration and application files inside the web root\ncan be overwritten, and a persistent implant can be dropped into a location\nthe product itself serves, surviving a service restart as an ordinary file\nin the served tree until an operator finds it.\n\nEverything in the chain is a shipped default, established from artifacts\nrather than from lab state: the endpoint exists in the shipped web root\n(squashfs extraction, byte-exact), the endpoint requires no authentication\n(absent include plus absent server-layer gate, both artifacts), the\ndestination is client-controlled (the copy() second argument is the\nmultipart filename, from the endpoint source), the destination directory\nis served and executable (document root and fastcgi mapping, both from the\nrecovered configuration), and the listener accepts connections from any\naddress.\n\nThe authentication model, named for what it is. The recovered lighttpd\nconfiguration declares its module list explicitly and loads no\nauthentication module; a content search of the recovered configuration for\nan authentication backend, an authentication module, a valid-user\nrequirement and an access-denial rule returns zero hits for all four\npatterns. The gate, where it exists at all, is one include statement inside\neach PHP file, so the product\u0027s authentication boundary is exactly as\nstrong as its most forgettable file, and upload.php is that file. The\nboundary claim is deliberately conservative: this handler is established\nas unauthenticated by the byte-exact source plus the absent server-layer\ngate, and no claim is made about other handlers in the web root, which are\nnamed in the advisory as an audit recommendation, not as findings.\n\nVerification boundary, stated in full, because it defines what is and is not\nbeing claimed. No physical Crystal VM was reachable during this study, so\nthe verification could not be a live drive against the product\u0027s own\nlistener. The static half is anchored in the appliance disk image: the\nOVA\u0027s VMDK was converted to a raw image, the PHP web root was carved out of\nits squashfs region (653 inodes, 575 files, including the byte-exact three-\nline upload.php), and the server configuration was recovered from the same\ndisk and read in full. The dynamic half ran on a faithful replica: the\nappliance\u0027s own extracted web root, all recovered files including the real\nupload.php, served with the document-root behaviour and the\nunauthenticated-execution semantics of the appliance\u0027s own extracted\nconfiguration, on the loopback interface of an isolated research host.\nThree independent runs uploaded the probe file without any credential,\nconfirmed the landing in the document root, and returned an execution\nmarker together with command output on one fetch; a no-upload negative\ncontrol produced no marker (and a fetch of never-uploaded names returned\n404 with nothing); and an absolute-destination variant, writing to an\nabsolute path inside the served root, landed and executed identically, so\nthe write does not depend on a working-directory coincidence. The exact\nworking-directory resolution of a relative destination on a shipped\nappliance is the one piece this work could not observe on physical hardware,\nwhich is why the absolute-destination result exists and why the chain does\nnot rest on it.\n\nOn the executing identity, because it matters for what downstream readers\nshould and should not claim. The command output in the replica runs\nidentified the invoking account of the replica\u0027s PHP server process. That\nmeasurement is a property of the replica environment and is reported as\nsuch: it demonstrates that executed code inherits the identity of the PHP\nservice. The corresponding identity on a shipped appliance, the lighttpd\n/ php-cgi service account of the VM, was not observed at runtime in this\nwork, and no superuser claim appears anywhere in the advisory. The\nexecution primitive, the score and the impact statements are written to be\ntrue whichever account that turns out to be; a reader who sees a 9.8 vector\nand starts writing \"root on the appliance\" is jumping past the published\nevidence, and this disclosure says so plainly rather than benefiting from\nthe inflation.\n\nScoring. One score is published: 9.8 Critical,\nCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, re-derived rather than\ninherited. The arithmetic is printed so any reader can reproduce it under\nthe CVSS 3.1 base algorithm and its round-up-to-the-tenth rule: ISS =\n1 - (0.44 x 0.44 x 0.44) = 0.914816; Impact for Scope Unchanged = 6.42 x\n0.914816 = 5.869119; Exploitability = 8.22 x 0.85 x 0.77 x 0.85 x 0.85 =\n3.887043; the unrounded base is 9.756162 and Roundup gives 9.8. A\nscope-changed reading that would compute to 10.0 is published as rejected:\nno violation of an authority beyond the web service itself was\ndemonstrated, the uploaded file executing in the product\u0027s own PHP process\ncontext, and whether that process\u0027s account additionally holds host\nprivileges is an unmeasured deployment property the advisory declines to\nclaim. A conditional reading at 8.8 High (from Exploitability 2.835255 and\nsum 8.704374) applies to deployments that confine the appliance to a\nsegmented management network; the shipped recovered configuration\nestablishes no such confinement, so the published score uses the measured\nnetwork bind and the conditional is labelled, not measured.\n\nImpact. Server-side code execution on the video management server through\nthe product\u0027s own fastcgi mapping, with no payload delivery beyond plain\nHTTP or HTTPS and no credential at any point, plus an anonymous arbitrary\nfile write into the served tree that persists across service restarts.\nWhat the web service account reaches is exposed to attacker-chosen code:\nthe application\u0027s own state, recorded media indices, camera trees, applied\nconfiguration, and whatever the service account can read on the appliance\nfilesystem, with arbitrary modification of served content and complete\ncontrol of service availability. Detection is hard by construction: both the\nwrite and the execution use the product\u0027s handled paths and ordinary\nstatus codes, leaving file-integrity monitoring of the web root and\nconfiguration-change review as the defenders\u0027 strongest signals. Two\nconsequence classes are plausible and explicitly not claimed, because they\nwere not measured: takeover of downstream cameras and recorders through\nstored management credentials, and lateral movement through the camera\nnetwork. The amplifying architecture weakness is reported alongside the\nfinding and not folded into the score: authentication implemented\nfile-by-file means every PHP handler that forgets the session include is\nunauthenticated by design, and upload.php is the one measured here.\n\nMitigation summary: remove upload.php or place its function behind the\nproduct\u0027s authenticated session gate, which severs the chain at request\none; never build a storage destination from request data, generating the\nstored name server-side from an allow-listed extension set and\ncanonicalising the resolved destination against an intended storage root;\nstore uploads outside the served tree in a non-executable quarantine\ndirectory with randomized names; move authentication from the file level to\nthe server or framework level so one forgotten include cannot reopen an\nanonymous handler, and while that migration is pending mechanically audit\nevery handler in the web root for the missing-include pattern, which in\nthis product is a grep-sized task; add a shipped-image manifest of the\ndocument root reconciled at boot or on a schedule, a day-scale engineering\neffort for an appliance that detects this class of implant; and add\nregression tests expressing the three omissions as assertions: an\nunauthenticated upload with a .php destination rejected, a session-less\nwrite to any handler rejected, and the stored destination differing from\nthe client-supplied name. For operators until a patch ships: restrict\nmanagement reachability to a segmented network, run file-integrity\nmonitoring on the document root, and treat unexpected served-content\nchanges as a standing signal.\n\nThe published proof of concept is Python 3 using only the standard library.\nIt performs one credential-less multipart POST carrying the probe file with\na chosen destination name and one fetch of that name, printing the\nresponse; the success criterion is an execution marker in the fetched body,\nso a servable-but-not-executing write cannot false-positive. A control mode\nperforms no upload and asserts nothing executes, mirroring the negative\ncontrol used during verification. The command the probe runs is supplied by\nthe operator and the published default is a non-destructive identity query.\nNo reverse shell, no callback channel, no persistence installer and no\ndestructive command is provided or was run.\n\nFull technical analysis and the reproducible proof of concept, published\nunconditionally:\n  https://0day-rubbish.com/blog/nuuo-crystal-server-unauth-upload-php-webroot-write-rce\n\nPoC location in the public repository:\nproduct/nuuo/crystal-server-3.19.0.85/unauth-upload-php-webroot-write-rce/exploit/nuuo_crystal_server_unauth_upload_php_webroot_write_rce.py\n\nProject archive (ongoing disclosure series):\n  https://github.com/Exploit-Garbage/0day-Rubbish\n\nThe vendor publishes no RFC 9116 security.txt: the well-known path returns\nthe site\u0027s own 404 on the www host and on the apex, as does the\nnon-well-known fallback path, and the vendor\u0027s own page index contains no\nsecurity, vulnerability-reporting or responsible-discl"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-306",
              "description": "CWE-306",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-434",
              "description": "CWE-434",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-73",
              "description": "CWE-73",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-11-02T07:30:04Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/56"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Oct/56"
        },
        {
          "url": "https://0day-rubbish.com"
        },
        {
          "url": "https://0day-rubbish.com/blog/nuuo-crystal-server-unauth-upload-php-webroot-write-rce"
        },
        {
          "url": "https://github.com/Exploit-Garbage/0day-Rubbish"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Oct/56"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "[0day-rubbish] NUUO Crystal Server 3.19.0.85 unauthenticated upload.php PHP web-root write with fastcgi execution into server-side code execution as the web service account (9.8 Critical)",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0505",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/56",
            "automated": true,
            "contentSha256": "398d33967e157b5fddc8742b259ee4e769fe2a28ff200670d7b82d9ba4d1cd61",
            "evidenceScore": 11,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Oct/56",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-10-27T16:39:30Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-11-02T07:30:04Z",
    "dateUpdated": "2026-11-02T07:30:04Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0505"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "ProSoft Technology RLX-IFH24E",
          "vendor": "unknown",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "disclosure via Fulldisclosure"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "0day Rubbish Research Team is publicly disclosing a vulnerability in the\nProSoft RLX-IFH24E, version v2.2.44, the industrial wireless radio from\nProSoft Technology, Inc. (United States). The appliance is a closed-source\nembedded device and an OEM build of the MicroHard Systems IPx21 platform on\nthe MHX-910 board design: an Intel IXP425 XScale processor, ARM\nbig-endian, Linux 2.4.24-uc0, with static management pages under /usr/web\nand 57 ARM big-endian CGI programs under /usr/lib/cgi-bin/ served by boa\nover HTTP and boa_ssl over HTTPS.\n\nThe vendor is identified precisely here, by its legal name, its published\nheadquarters address and its support domain, because a different and\nunrelated company trades under a similar name in another country, and this\nresearch concerns the United States industrial radio vendor only. ProSoft\nTechnology\u0027s own legal pages give the entity as ProSoft Technology, Inc.,\n9201 Camino Media, Suite 200, Bakersfield, CA 93311, USA, and its support\npages note that support addresses moved from the vendor domain to\nbelden.com, the domain of its parent company.\n\nTHE EVIDENTIAL BOUNDARY, BEFORE ANYTHING ELSE\n\nThis disclosure has an unusual evidentiary shape and it is stated up front\nso that no reader over-reads it. No HTTP request was ever issued at this\nproduct. No physical appliance was used at any point. The chain is therefore\nnot presented as an exploit run against a live device, and it is not one.\n\nThe finding has two halves. The installer half was measured: the firmware\u0027s\nown /sbin/upgrade script and the other scripts in /sbin were executed\nbyte-for-byte unmodified inside an isolated chroot sandbox built on a copy\nof the upgrade package\u0027s own root filesystem, with marker files and a\nrecorded executing uid as the evidence. The upload half was inferred: it\nrests entirely on disassembly of the shipped ARM big-endian CGI and of the\nshared platform UI library, and nothing in it was observed in motion. The\nline between those two halves runs down the middle of the chain and is drawn\nexplicitly wherever it appears in the published analysis.\n\nTYPE AND ROOT CAUSE\n\nCode installed and executed without an integrity or authenticity check.\nCWE-494 is the primary classification, with CWE-345 and CWE-347 co-equal\nbecause the only check anywhere in the path is a non-cryptographic string\nequality and no signature is verified at any point. CWE-434, CWE-73, CWE-250\nand CWE-269 are contributing and are reported separately without raising any\nmetric. This is explicitly not CWE-78: no command string is injected at\neither hop, so a command-injection remediation, filename input filtering or\nshell escaping would not close the chain. The shared platform helper\nSubProgram_Start at offset 0xbd5c splits its argument string on spaces with\nstrtok into at most eight tokens and then calls vfork and execvp directly,\nso no shell is involved at all.\n\nThe system upgrade package RLX-IFH24E_v2244.pkg contains four artefacts\nthat together describe the whole path: the upload handler\nusr/lib/cgi-bin/tool_reprogramming.cgi, the installer /sbin/upgrade that it\ninvokes as a root process, the factory account database /etc/passwd, and\nthe default configuration store /etc/db1.\n\nThe upload hop, recovered by disassembly. HandleSubmit at offset 0x8d1c\ntakes the file1 part of a multipart/form-data POST to\n/cgi-bin/tool_reprogramming.cgi and performs this sequence, with the format\nstring sitting at rodata offset 0x2b1c:\n\n    cgiFormFileName(\"file1\")     -\u003e the client\u0027s original filename\n    cgiFormTempFileName          -\u003e path of the temporary body file\n    sprintf(buf, \"%s /upgrade/upgrade/%s\", tempfile, origfilename)\n    SubProgram_Start(\"/bin/mv\", buf)              ; must succeed first\n    SubProgram_Start(\"/sbin/upgrade\", origfilename)\n\nThe original client filename is used unmodified twice: once to build the\ndestination of the move, and once as the installer\u0027s only argument. That\nmakes the file extension, and therefore the branch the installer takes,\nentirely the requester\u0027s choice. The handler applies no extension\nwhitelist, no digest comparison and no path canonicalisation.\n\nThe installer hop, executed and observed. /sbin/upgrade is a short POSIX\nshell script that runs with the privileges of the CGI that invoked it,\nwhich are root, and dispatches purely on ${FILE##*.}:\n\n    case \"$EXT\" in\n      passwd)  cp /upgrade/upgrade/$FILE /etc/passwd\n               cp /upgrade/upgrade/$FILE /etc/passwd_original ;;\n      factory) cp /upgrade/upgrade/$FILE /etc/db1 ;;\n      pkg)     gunzip -t /upgrade/upgrade/$FILE || exit 1\n               tar -xf /upgrade/upgrade/$FILE -C \u003cstaging\u003e\n               [ \"$DEVICE_PRODUCT_NAME\" = \"$PKG_LOCK_NAME\" ] || refused\n               echo \"Match image.\"\n               ./pre\n               tar -xf extract/upgradepkg.tar -C /\n               ./post\n               echo \"Upgrade Successful\"\n               reboot ;;\n    esac\n\nThe .pkg branch is the code-execution primitive. ./pre runs before anything\nelse is applied, so requester-authored code executes against the pristine\nfilesystem and can read the old state; tar -xf extract/upgradepkg.tar -C /\napplies an inner archive whose entry names are constrained in no way, which\nis an arbitrary rootfs write; ./post runs after the write, so the same\nrequester also sees the new state; and the branch ends in an unconditional\nreboot, which makes the change persistent and destroys the runtime\nevidence. The .passwd branch is a second, independent route to the same\nprivilege ceiling and it needs no execution at all: it copies the upload\nover both the live account database and the backup copy, so the device\u0027s own\nrecovery path restores the modified database rather than the shipped one.\nThe .factory branch is the same primitive aimed at the configuration store.\n\nThe only validation the installer performs before executing package content\nis a string equality, and both of its operands are available to whoever\nsupplies the package. The expected value DEVICE_PRODUCT_NAME is read from\nthe appliance\u0027s own platform identity file /etc/MHX_CONFIG, where this\nfirmware records PRODUCT_NAME=IPx21PROSOFT, a compile-time constant\nrecoverable by reading the shipped firmware once. The asserted value\nPKG_LOCK_NAME is read from a file called lockfile inside the package being\ninstalled. A package whose identity is validated against a value carried\ninside that same package is not a source of assurance about that package.\nThe gunzip -t test beside it is a gzip stream-integrity check and proves\nonly that the file is well-formed. The check that exists was never meant to\nanswer the authenticity question, and strengthening it would change nothing\nwhile the requester supplies both sides; what is missing from the path\nbetween an HTTP request and root execution is any authenticity step at all.\n\nWHAT WAS MEASURED\n\nA crafted .pkg carrying the correct platform string was placed in the\nstaging directory, reproducing by hand the state the handler\u0027s /bin/mv step\nwould have produced, and the unmodified installer was invoked on it. It\nprinted \"Match image.\" and then \"Upgrade Successful\" and exited 0. Four\nindependent effects were observed on the sandbox filesystem: the pre and\npost scripts left markers proving both executed; the inner archive left a\nmarker at the root of the filesystem, proving the unconstrained extraction;\nand a marker file written by the payload at runtime contained\nPRE-RAN-AS-UID=0. That last value is the load-bearing line, because the\npayload wrote it during execution rather than having it read from a\nconfiguration file, so it is the executing identity and not an inference\nabout it. The recorded landing identity for this finding is uid=0(root).\n\nA .passwd run was performed the same way. Both /etc/passwd and\n/etc/passwd_original were replaced by the uploaded text: the digest\nrecorded for the pre-seeded database before the run no longer matched\nafterwards, and the marker line was present in both copies. The marker line\ngrants a uid-0 account with /bin/sh, which on this product is the\ndifference between the factory admin shell /bin/txtUI and a general root\nshell available at the next interactive login.\n\nA negative control establishes that none of that came from the harness. A\nstructurally identical package, same outer tar layout, same metadata files,\nsame inner archive, same marker-writing scripts, with exactly one deliberate\ndifference, LOCK_NAME=WRONGPRODUCT, was refused with \"This unit doesn\u0027t\nsupport the image.\" and produced no markers anywhere. Three conclusions\nfollow: the markers are produced by the install path; the observed success\nwas conditional on that one string comparison, so the check is bypassable by\nsupplying the documented string rather than being irrelevant; and the\npositive and negative runs are mutually exclusive, so the positive result\ncannot be explained by a sandbox in which everything appears to succeed.\n\nThe run count is stated exactly because it is small. One positive .pkg run,\none positive .passwd run and one negative control run, in one sandbox on one\nhost, with each effect observed once. The runs were not repeated across\nmultiple sandbox builds and were never performed on hardware.\n\nFour substitutions were made in the harness and none in the code under test.\nThe firmware is ARM big-endian and the sandbox host is not, so an x86\nbusybox build supplied /bin/sh, tar, gunzip, mv and cp; a stub replaced the\nplatform mhx utility; /etc/MHX_CONFIG was populated with the product\nidentity the firmware itself ships; and /etc/passwd was pre-seeded with\nthree factory-style entries so that a before and after comparison was\npossible. Two lines appearing in the transcript, \"logger: not found\" and\n\"mhx: not found\", are absent helpers in the sandbox PATH and are not product\nbehaviour; they are reproduced rather than suppressed, because concealing a\nnegative-looking line would misrepresent the run.\n\nWHAT WAS NOT MEASURED\n\nNo physical appliance was used. No HTTP request was issued to the product\nand the uploader hop was never executed; the staging file was placed by\nhand. The web server was not executed and could not have been, because\n/bin/boa lives in the device base flash and is not contained in the system\nupgrade package, and it is boa that decides whether a client is allowed to\nfork a CGI at all. Its access control could therefore be neither proved nor\ndisproved from the artefacts available. The CGI binaries and the firmware\u0027s\nown ARM helper utilities were not executed for the architecture reason. The\nreboot closing the .pkg branch did not happen, since the sandbox is a\ndirectory tree with no init; the path leading to it was observed up to that\npoint. No privilege escalation is claimed, the chain starting from the\nadministrative identity the product\u0027s own account database already grants\nuid 0. There is no claimed reach into the radio baseband image\nRLX-IFH24E_v5089.mhx, which was identified but not exercised, and no\ndemonstrated impact on any attached control system, PLC or historian.\n\nAUTHENTICATION\n\nThe finding is published as requiring administrative privilege. The package\ndocuments its own account model:\n\n    admin:   \u003cDES-crypt hash\u003e:0:0:admin:/:/bin/txtUI\n    upgrade: \u003csame DES-crypt hash\u003e:500:500:ftpupgrade:/upgrade/upgrade:/bin/sh\n\nThe admin account is uid 0, so the management stack is not\nprivilege-separated and an administrative login already holds the privilege\nthe sink needs. Its shell is /bin/txtUI, a restricted interactive interface\nrather than a general shell, which is a user-interface constraint and not a\nsecurity boundary once arbitrary code execution is available. A second\naccount exists with uid 500, a working /bin/sh, the same password hash, and\na home directory that is precisely the upload staging path. The interface\nalso carries a password-change page and a configurable RADIUS mode. The\nfactory credential itself is not reproduced here; the published advisory\ndeliberately withholds that hash.\n\nWhat the package establishes about th"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-250",
              "description": "CWE-250",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-269",
              "description": "CWE-269",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-345",
              "description": "CWE-345",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-347",
              "description": "CWE-347",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-434",
              "description": "CWE-434",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-494",
              "description": "CWE-494",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-73",
              "description": "CWE-73",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-78",
              "description": "CWE-78",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-11-02T07:30:03Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/32"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Oct/32"
        },
        {
          "url": "https://0day-rubbish.com"
        },
        {
          "url": "https://0day-rubbish.com/blog/prosoft-rlx-ifh24e-unsigned-upgrade-package-root-rce"
        },
        {
          "url": "https://github.com/Exploit-Garbage/0day-Rubbish"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Oct/32"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "[0day-rubbish] ProSoft Technology RLX-IFH24E v2.2.44 unsigned firmware upgrade package to root command execution and full account-database overwrite (7.2)",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0498",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/32",
            "automated": true,
            "contentSha256": "3acb301f966d5f251d5745d10e0d57410089cad24deea1811b7cf44ad01e0857",
            "evidenceScore": 11,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Oct/32",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-10-20T02:31:17Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-11-02T07:30:03Z",
    "dateUpdated": "2026-11-02T07:30:03Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0498"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-0496",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-01-13T15:15:16.379852Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-01-13T15:15:21.939Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "SAP Fiori App (Intercompany Balance Reconciliation)",
          "vendor": "SAP_SE",
          "versions": [
            {
              "status": "affected",
              "version": "UIAPFI70 500"
            },
            {
              "status": "affected",
              "version": "600"
            },
            {
              "status": "affected",
              "version": "700"
            },
            {
              "status": "affected",
              "version": "800"
            },
            {
              "status": "affected",
              "version": "900"
            },
            {
              "status": "affected",
              "version": "901"
            },
            {
              "status": "affected",
              "version": "902"
            },
            {
              "status": "affected",
              "version": "S4CORE 102"
            },
            {
              "status": "affected",
              "version": "103"
            },
            {
              "status": "affected",
              "version": "104"
            },
            {
              "status": "affected",
              "version": "105"
            },
            {
              "status": "affected",
              "version": "106"
            },
            {
              "status": "affected",
              "version": "107"
            },
            {
              "status": "affected",
              "version": "108"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eSAP Fiori App Intercompany Balance Reconciliation allows an attacker with high privileges  to upload any file (including script files) without proper file format validation. This has low impact on confidentiality, integrity and availability of the application.\u003c/p\u003e"
            }
          ],
          "value": "SAP Fiori App Intercompany Balance Reconciliation allows an attacker with high privileges  to upload any file (including script files) without proper file format validation. This has low impact on confidentiality, integrity and availability of the application."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "LOW",
            "baseScore": 6.6,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "LOW",
            "privilegesRequired": "HIGH",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:L",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-434",
              "description": "CWE-434: Unrestricted Upload of File with Dangerous Type",
              "lang": "eng",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-01-13T01:13:28.818Z",
        "orgId": "e4686d1a-f260-4930-ac4c-2f5c992778dd",
        "shortName": "sap"
      },
      "references": [
        {
          "url": "https://me.sap.com/notes/3565506"
        },
        {
          "url": "https://url.sap/sapsecuritypatchday"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Multiple vulnerabilities in SAP Fiori App (Intercompany Balance Reconciliation)",
      "x_generator": {
        "engine": "Vulnogram 0.5.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "e4686d1a-f260-4930-ac4c-2f5c992778dd",
    "assignerShortName": "sap",
    "cveId": "CVE-2026-0496",
    "datePublished": "2026-01-13T01:13:28.818Z",
    "dateReserved": "2025-12-09T22:06:38.258Z",
    "dateUpdated": "2026-01-13T15:15:21.939Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "Pal",
          "vendor": "Maian",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "disclosure via Fulldisclosure"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "0day Rubbish Research Team is publicly disclosing a vulnerability in Maian Pal\n2.1, the self-hosted PHP shopping-cart script from Maian Media (United Kingdom),\noriented at PayPal checkout and distributed as a commercial closed-source archive,\nverified end to end against a real installation of that version in three\nindependent reproductions.\n\nType: unrestricted upload of a file with a dangerous type (CWE-434 primary, with\nCWE-94 and CWE-693 contributing - the stored object is subsequently interpreted as\ncode, and the served upload directory lacks the execution restriction that\nequivalent directories in the same product carry), realised as OS command\nexecution (CWE-78 describes what the demonstration payload does once it runs and\nis not scored separately). The product-image handling of the administration\nproduct create and update operations, `ajax-ops=add` and `ajax-ops=add-edit`,\npasses the multipart field fm[ifile][] to products::pictures() at\n`class.products.php:333` through `class.products.php:410`. The stored name is\nchosen from the client-supplied filename by a single ternary:\n\n    // class.products.php:372  - no extension allow-list anywhere on this path\n    $picPath = ($cfg[\u0027rename\u0027] == \u0027yes\u0027\n                ? $cfg[\u0027imgprf\u0027] . $ID . \u0027-\u0027 . $nextPic . strrchr($name, \u0027.\u0027)\n                : $name);\n\n    // class.products.php:~390  - written before any validation\n    move_uploaded_file($temp, $picFldr . \u0027/\u0027 . $picPath);\n\nWith $cfg supplied by thumbcfg() at `class.products.php:615`, whose shipped\ndefault is \u0027rename\u0027 =\u003e \u0027no\u0027, that assignment reduces to $picPath = $name, so the\nclient controls the entire stored name including the extension and a .php file\nlands on disk intact as content/products/\u003cID\u003e/\u003cname\u003e.php. There is no extension\nallow-list and no deny-list, no finfo or MIME verification, no re-encoding to\nstrip an embedded payload, no server-generated filename with a type-derived\nextension, and no rollback of the write when later validation fails. strtolower()\nappears only in the non-default rename=\u0027yes\u0027 branch and is cosmetic.\n\nThe root cause has two independently fixable halves, and this advisory keeps them\nseparate because fixing one without the other leaves the chain standing.\n\nThe first half is the handler: what may be written. The second is the directory:\nwhether what is written may execute. That second half lines up in this product\nbecause the destination sits inside the document root and the front-controller\nrewrite claims only paths that do not exist on disk - `RewriteCond !-f` guarding\n`RewriteRule ^([^?]*) index.php?_msw_=$1 [L,QSA]` - so a file that exists is handed\nstraight to the PHP handler, and requesting it with a query string executes it.\nNothing in content/products/ disables that handler. Our review of the shipped tree\nfound an Apache deny file carrying `Deny from all` present in admin/import/, and\nfound content/products/ carrying no such file.\n\nThe contrast that makes this an omission rather than a design decision is inside\none product and one shipped version: two handlers accept files from a browser, and\none of them checks the extension and writes into a deny-protected directory while\nthe other does neither. We are precise about the evidentiary weight of each half\nof that comparison, because it matters. That admin/import/ carries `Deny from all`\nand that content/products/ carries nothing are both anchored artefacts of the\nshipped tree. The statement that the product\u0027s attachment upload path applies an\nextension allow-list into a deny-protected directory is a source-level reading of\nthe shipped PHP that we did not reduce to a line citation, and we label it as\nsuch. It is offered here the same way we put it to the seller: as a contrast worth\nconfirming, since part of the argument that this is an omission rests on it.\n\nThe ordering inside the handler makes the failure path worse rather than safer,\nand this is the detail most likely to be missed by a fix that only adds a check\ndownstream. move_uploaded_file() runs before any thumbnail inspection, and the\nvalidation that does run is not fatal. getimagesize() inside thumbnail() runs\nafter the write and is used only to select a thumbnail strategy, never to accept\nor reject the upload; for a PHP file it fails, the switch falls through to a\nsuppressed @copy(), and the original is never unlinked. So a non-image upload\nleaves two objects in a served directory - the original plus a tmb_-prefixed\nsibling - deletes neither, and still reports {\"status\":\"ok\"}. The failure path\nyields two files rather than zero, silently. Any cleanup that removes only the\nobviously named object leaves the second one behind.\n\nTurning rename on would not fix this either, and it deserves emphasis because it\nis the obvious operator-facing knob: in the rename=\u0027yes\u0027 branch the stem is\nserver-generated but the extension is still taken from the client filename via\nstrrchr(), so a .php upload produces a server-named file that is still\nexecutable. We derived that from the assignment expression and did not run the\nrename=\u0027yes\u0027 configuration, so it is an argument from code rather than a dynamic\nresult.\n\nCommands execute as the web server service account, observed as\n`uid=33(www-data) gid=33(www-data) groups=33(www-data)` in three independent\nreproductions with distinct random filenames, plus a marker written to an absolute\npath outside the document root and read back afterwards from the host. No\nprivilege escalation of any kind was attempted or observed: no kernel exploit, no\nsudo right, no writable service unit, no container escape. Root was not reached\nand is not claimed; the ceiling of this finding is code execution as the web\nserver user.\n\nHow confirmation works. The chain is two requests. One POST creates the object\nand the create response itself embeds `?p=add\u0026id=\u003cID\u003e`, so the attacker learns\nthe numeric product directory without guessing and the filename is one they\nchose - predictability of the final URL is total. One GET to\n`/content/products/\u003cID\u003e/\u003cname\u003e.php?cmd=\u003ccommand\u003e` executes it and returns the\noutput in the response body, prefixed by a marker that proves the body came from\nPHP execution rather than from static file serving. Both operations report\n{\"status\":\"ok\"}. What was deliberately not reproduced: no data theft, no database\nmodification, no persistence beyond the uploaded file, no lateral movement and no\nexploitation of a live third-party system - all verification targeted our own\ninstance, and the payload\u0027s default command is a non-destructive identity query.\n\nScoring. One score is published: 7.2 High,\nCVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H, the CVSS 3.1 base arithmetic for\nwhich is shown in full in the advisory and was re-checked against an independent\nimplementation of that formula. AV:N because the sink sits on the product\u0027s\nordinary HTTP(S) listener, with no separate management port, no RPC endpoint and\nno background listener, and nothing in the chain depends on source address, user\nagent or session age beyond validity. AC:L because one POST creates the object and\none GET executes it, so there is no race window, no multi-step state to prepare and\nno unusual configuration requirement: the chain depends only on shipped defaults\n(thumbcfg() \u0027rename\u0027 =\u003e \u0027no\u0027, no deny file in content/products/), and the licence\nrestriction RESTR_PRODUCTS = 50 does not obstruct the first product create. UI:N\nbecause no victim browser or user action is involved - the attacker authenticates\nwith their own credentials and there is no forgery step.\n\nPR:H is published because only an authenticated administrator session was\ndemonstrated. The credential pair is the one the installer provisions (LG_USER\nand LG_PASS in `control/_cfg.php`), mswPerms() gates every administration\noperation except login and logout, and no graduated back-end role was shown to\nreach ajax-ops=add. Four named alternative readings are published against that\n7.2 so that each rejection is auditable, and one of them is conditional rather\nthan rejected:\n\n  - Scope Changed, AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H = 9.1. Rejected. The\n      vulnerable component is the administration back-end and the impacted\n      resources are that application\u0027s own files, its own database reached with\n      the very credentials the application holds, and the operating-system\n      context of the web server process it runs inside. The achieved identity is\n      the same service account the application always ran as, on the same host,\n      and nothing outside its reach before the upload came into reach\n      afterwards. Publishing S:C would require a database-server compromise\n      independent of the application\u0027s credentials, a container escape or a\n      distinct host, and none was demonstrated.\n  - Unauthenticated, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8. Rejected, and\n      this is the tempting headline for a public-facing shopping cart that we\n      decline to print as ours. The storefront dispatcher\u0027s 56 unauthenticated\n      AJAX operations contain no file-upload, command-execution, code-evaluation\n      or deserialization primitive - only include() of language and class files -\n      the administration login was reviewed on six specific bypass axes with no\n      success, and the product ships no factory credential and no usable\n      SECRET_KEY.\n  - Lower-privileged back-end role, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 8.8.\n      Published as a conditional reading, labelled as such and never as the\n      headline. The dispatcher exposes users, users-edit, permissions and\n      permissions-edit, so the product may model back-end accounts narrower than\n      the single installer-provisioned administrator; mswPerms() was established\n      in our review only as an authentication gate over the dispatch, not as a\n      per-operation authorization matrix; and no principal short of full\n      administrator was demonstrated reaching ajax-ops=add. If a restricted\n      back-end account can create or update products, that account is the\n      least-privileged principal reaching the sink and PR:L is the faithful\n      metric, at Impact 5.87311872 plus Exploitability 2.83525473, base\n      8.70837345, rounded up. We did not round our rating up to it, because\n      doing so would assert a privilege model we did not observe.\n  - Elevated complexity, AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H = 6.6, and user\n      interaction, AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:H = 6.8. Both printed only\n      so the rejections are inspectable: there is no race, no ordering constraint\n      beyond one POST and one GET, no requirement that the target be in an\n      unusual state, and no victim action at any point in the chain.\n\nContributing weaknesses are reported and deliberately not scored into the vector:\nthe single-round SHA-1 mswEnc() credential transform, loose `==` comparisons on\nhash and token strings, the absence of any enforced rotation of the\ninstaller-provisioned secret, and the inconsistency between upload handlers inside\none shipped version. None of them lowers the privilege required to reach the sink\nand none raises the impact of the upload once it is reached. There is also no\nnumeric base score in our own record against this vector that could disagree with\nit, so no correction notice accompanies the figure.\n\nAuthentication: post-authentication administrator plus the session CSRF token, and\nboth gates were treated as things to attack rather than as configuration to trust.\nThere are no factory credentials in Maian Pal 2.1: the installer forces LG_USER,\nLG_PASS and SECRET_KEY to be set, `control/_cfg-sample.php:62` ships only the\nplaceholder text \"Your secret key value goes here\", and this is not a\ndefault-credential report. The login path was reviewed for a missing or permissive\npermission configuration, a route that skips the gate, a predictable CSRF token, a\npre-computable credential hash, a factory-credential fallback, a\ncomparison-timing difference and a secondary authentication branch, and none was\nfound; t"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-434",
              "description": "CWE-434",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-693",
              "description": "CWE-693",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-78",
              "description": "CWE-78",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-94",
              "description": "CWE-94",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-11-02T07:30:02Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/17"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Oct/17"
        },
        {
          "url": "https://0day-rubbish.com"
        },
        {
          "url": "https://0day-rubbish.com/blog/maian-pal-product-image-upload-webshell-rce"
        },
        {
          "url": "https://github.com/Exploit-Garbage/0day-Rubbish"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Oct/17"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "[0day-rubbish] Maian Pal 2.1 product image upload with no extension allow-list to PHP webshell and www-data uid 33 code execution (7.2, PR:H)",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0488",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/17",
            "automated": true,
            "contentSha256": "0b3e889b1e4a4dcd1911310cb807a8368fb210a07e78930cca78dfad7f6238a2",
            "evidenceScore": 11,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Oct/17",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-10-13T02:22:02Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-11-02T07:30:02Z",
    "dateUpdated": "2026-11-02T07:30:02Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0488"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "COMmander 6000",
          "vendor": "Auerswald",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "disclosure via Fulldisclosure"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "0day Rubbish Research Team is publicly disclosing a vulnerability in Auerswald\nCOMmander 6000 and COMmander 6000R, firmware 8.6D build 128154, the\nclosed-source enterprise IP-PBX and unified-communications appliances from\nAuerswald (Germany). Two unauthenticated HTTP requests, carrying no cookie and\nno credential of any kind, yield uid=0(root) gid=0(root) groups=0(root) on an\nappliance that holds extension credentials, SIP trunk credentials, call detail\nrecords and voicemail for every user it serves.\n\nType and root cause. CWE-22, path traversal in the zip-slip form, inside a\nroot archive extraction; CWE-73, CWE-434, CWE-862 and CWE-250 contribute. The\nfinding is explicitly not classified as CWE-78, and this is worth stating\nbecause it changes the fix: no command string is injected at either hop, and\nevery argument to every observed execve is either a compile-time constant or a\nvalue that passed the product\u0027s own whitelist legitimately. Escaping and\ncharacter whitelisting are already implemented correctly in this product. The\nmissing controls are archive containment and route authorization, and a\ncommand-injection patch would close nothing.\n\nThe chain has two hops and both are needed. Hop 1 is the write primitive: the\nunauthenticated route /provisioning_data_import stores one multipart/form-data\npart at /data/provisioning/import/\u003cbasename\u003e and then spawns, as root,\n\n    posix_spawn(\"../minizip/miniunz\", \"-o\", \"-x\", \u003czip\u003e, \"-d\",\n                \"/data/provisioning/import/\")\n\ncaptured verbatim from the syscall trace of the product\u0027s own process. Neither\nthe application nor the bundled extractor inspects archive entry names, so an\nentry named ../../../opt/auerswald/hping2 escapes the extraction directory and\noverwrites a root-owned mode-0755 binary with attacker bytes. Because the write\ntruncates an existing file, the original permission bits survive and the result\nis immediately executable; there is no separate chmod primitive and none is\nneeded. The -o flag is what makes the replacement silent, converting the\nextractor\u0027s refuse-to-clobber default into clobber-without-prompt. Hop 2 is the\nconsumer: a second unauthenticated request to /netdiagnostic_execute makes root\nrun\n\n    /bin/sh -c \"/opt/auerswald/hping2 -1 -I eth0  -c 3 \u003ctarget\u003e -p \u003cport\u003e\"\n\nThe diagnostics handler validates the target argument against the charset\n0-9A-Za-z.-:/ and that whitelist works as intended; what it cannot protect is\nthe bytes sitting at a path that appears as a compile-time constant in the\ncommand. The kernel honours the attacker\u0027s #!/bin/sh shebang, and the payload\u0027s\nstdout is captured into the HTTP response body, so the result is read back\ndirectly and no out-of-band channel is involved. Both handlers live in the\nvendor\u0027s own in-house FastCGI application, a 3,498,560-byte binary started by\ninit as root behind a stock lighttpd 1.4.64 on an ARM32 glibc embedded Linux\nuserland, which never drops privilege. The rootfs contains no suid or sgid\nbinary at all, so there is no privilege boundary between the web application\nand the operating system.\n\nHow confirmation works. Request 1 is a multipart POST whose part name is equal\nto the filename. That is the vendor\u0027s own client contract, recovered from the\nshipped JavaScript, which appends the file object to a FormData under the\nfile\u0027s own name; requests built the conventional way with a fixed field name\nare rejected by the application\u0027s parser, and that failure is indistinguishable\nfrom \"the server filters uploads\" unless the client is read. Request 2 is an\nordinary urlencoded diagnostics POST. The payload echoes a run-unique token\nplus the uid and user name to stdout, which the handler returns in the response\nbody, and appends the output of id to a marker file under /data/log. The\npublished advisory prints the identity string and the landing paths but\ndeliberately not the per-run token or a marker filename from a specific run,\nsince both are artefacts of one execution on one testbed.\n\nWhat was deliberately not reproduced. No persistence was installed. The same\nwrite primitive reaches the init-respawned service scripts under\n/opt/auerswald/scripts/run-*, the lighttpd configuration and the web document\nroot; those targets are named as statically available so that a defender can\nscope an incident, and none was fired. No configuration database, certificate,\nprivate key, credential or call record was read or removed, and no destructive,\nencrypting or exfiltrating payload is published. One elegant approach was tried\nand does not work, which is recorded here because it is a reproduction trap:\noverwriting the extractor itself so that the next import request executes the\npayload. The slip write happens inside the currently executing extractor\nprocess, the target file ends up zero bytes long, and the next invocation fails\nwith ENOEXEC. The doctrine that follows is to never overwrite a binary that is\nexecuting the write.\n\nA correction to our own earlier reading of this chain, published because it was\nwrong and a maintainer could otherwise chase it. During this work we\nhypothesised that the rejections of conventionally built uploads were caused by\nthe web server not spooling request bodies to an upload directory, rather than\nby the part name. That hypothesis is withdrawn. mod_fastcgi forwards the body\nto the backend over the FastCGI STDIN stream whether or not it spools to disk,\nthe application parses that stream itself, and once the part name matched the\nfilename the bytes were stored correctly on the first attempt. Nothing about\nthe web server configuration was blocking the upload, and a change that added\nan upload directory directive would not have altered the outcome.\n\nScoring. One score is published: 9.8 Critical,\nCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The Impact Sub-Score is\n1 - 0.44^3 = 0.914816, Impact under Scope Unchanged is 6.42 * 0.914816 =\n5.873119, Exploitability is 8.22 * 0.85 * 0.77 * 0.85 * 0.85 = 3.887043, and\nthe sum 9.760162 rounds up to 9.8 under the CVSS ceiling-to-tenth rule.\n\nAn alternative reading is argued in the advisory and not adopted as the\nheadline: Scope Changed. A network-facing management service yielding host-wide\nroot on an appliance that also holds call records, extension credentials and a\nmanaged phone fleet is the kind of outcome Scope Changed was written to\nexpress, and AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H computes to 10.0 - the\nScope-Changed impact term is 6.128026, exploitability is unchanged at\n3.887043, the sum times 1.08 exceeds the maximum and is capped. We publish\nScope Unchanged because of one fact: the application is already uid 0 by\ndesign, and the rootfs contains no suid or sgid binary because the vendor\u0027s\ndesign never needed one, so there is no authority boundary between the web\ncomponent and the telephony component for the chain to cross. It exercises,\nthrough a defect, an authority the vulnerable component already held.\nPublishing 10.0 would attribute a boundary crossing this product\u0027s architecture\ndoes not have, and would obscure the more useful message to the maintainer: the\nprivilege separation that would make Scope Unchanged the comfortable answer is\nitself a fix worth making.\n\nAC:L is a decision, not a default. There is no race, no timing window, no\nmemory-layout dependency, no on-path position, no brute force and no dependency\non the hardware abstraction layer, and the chain was demonstrated twice, in the\nfreshly initialised state and again in a tightened state described below. The\none non-obvious requirement, the part-name-equals-filename contract, is\nattacker-side correctness recoverable from the vendor\u0027s own shipped client\nrather than an environmental condition. Amplifier facts observed elsewhere in\nthe image - an empty root password field in /etc/passwd with no /etc/shadow in\nthis image, the telnet facility behind an AccessLevel 6 route, a site-wide\nunsafe-inline CSP, an unenforced client certificate on the provisioning socket -\nare kept out of the arithmetic and reported separately, because folding them in\nwould inflate the vector. No CVSS figure was recorded alongside the\nverification, so there is no recorded number for this vector to disagree with.\n\nAuthentication: none, and that is proven rather than assumed. Both routes are\ndeclared AccessLevel 2 in the product\u0027s own route table and both answered 200\nto a request carrying no Cookie header and no Authorization header, not an\nexpired session but no session material at all. The route table in .data holds\n750 named entries, and the product\u0027s gate - one session and credential\nevaluator at 0x15958, which is the sole caller of the access check at 0xf5d68 -\ncovers the service-technician family (AccessLevel 4), the DAA/daemon family\n(AccessLevel 6), the two packet-capture routes registered under those families\nand one login route: twelve of 750. The remaining 738 answer 200 to a\ncookie-less request, and more than forty of them were sampled during mapping,\neach returning live configuration data or performing a state change. lighttpd\ncontributes nothing to authorization: its FastCGI configuration sends every URL\nto the backend socket, and three probes with no referer, with the ip-editor\nreferer and with an unrelated referer produced no access difference.\n\nThe strongest internal evidence that this is a systemic coverage gap rather than\ntwo unlucky omissions sits on a single shared handler. FUNC 0x3b018, which\nstreams a packet capture back to the caller, is registered three times under\nthree names: ethernettrace.pcap at declared level 2 answers 200, starts a root\ntcpdump on eth0 with snaplen 9018 and streams the capture to the requesting\nclient, while servicetrace.pcap at level 4 and daemontools.pcap at level 6 both\nanswer 401. Same function address, same code, opposite outcome, so\nauthorization in this product is attached to route families rather than to the\noperations those routes expose.\n\nWhat was not broken is credited explicitly. The login route is fail-closed:\nfour password values across four parameter alias sets each produced an empty\ncookie. The vendor service-technician challenge is not forgeable from the image\nbecause verification is public-key only, against two DER SubjectPublicKeyInfo\nblobs shipped in the firmware, and the device holds no private key; the\nresponse space is also only 65536 wide with a four-attempt lockout, so it is\nnot brute-forceable either. The ForceAdmin and BEARER branches of the session\nevaluator were not read instruction by instruction, so no claim is made about\nthem in either direction - unexamined is not disproved, and this chain does not\ndepend on them. The declared AccessLevel value in the route table is not the\nenforced level, and the product\u0027s own data proves it: the DAA login route is\nrecorded at level 0 and answers 401. We do not claim that all 738 unguarded\nroutes are individually dangerous; we map the population and prove the two\nmembers this chain needs.\n\nImpact: complete control of a device that terminates and records every call it\nserves. Root here means the SIP stack, the voicemail and voice-mail\ndistribution components, the DSP channel configuration, trunk configuration and\nevery extension the appliance serves, so calls can be placed, redirected,\nrecorded or dropped. The configuration database under /data/db/ carries fields\nincluding cryptPasswd, passwd, passwdLdap, AdminPasswd, AdminPasswdHash,\npasswordHash and remote_access_token; user certificate private keys sit under\n/data/certs/user-certs; SIP trunk and gateway credentials live in the\nprovisioning data; and toll fraud is the standard real-world monetisation of\nexactly this position, usually discovered on an invoice rather than through a\nsecurity alert. Call detail records, billing structures and voicemail content\nfor every user become readable - who called whom, when, for how long and at what\ncost - which for an organisation whose calls carry customer, legal, medical or\nfinancial content is a reportable data-breach event. The appliance auto-provisi"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-22",
              "description": "CWE-22",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-250",
              "description": "CWE-250",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-434",
              "description": "CWE-434",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-73",
              "description": "CWE-73",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-78",
              "description": "CWE-78",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-862",
              "description": "CWE-862",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-11-02T07:30:02Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/13"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Oct/13"
        },
        {
          "url": "https://0day-rubbish.com"
        },
        {
          "url": "https://0day-rubbish.com/blog/auerswald-commander-provisioning-import-zip-slip-binary-hijack-root-rce"
        },
        {
          "url": "https://github.com/Exploit-Garbage/0day-Rubbish"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Oct/13"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "[0day-rubbish] Auerswald COMmander 6000 / 6000R 8.6D unauthenticated provisioning import zip-slip to root binary hijack and root code execution (9.8)",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0484",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/13",
            "automated": true,
            "contentSha256": "90bd32a60dddb6a9db5288e380d35f5af6a5104470c7f965934f14043fbd4bcf",
            "evidenceScore": 11,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Oct/13",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-10-13T02:21:03Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-11-02T07:30:02Z",
    "dateUpdated": "2026-11-02T07:30:02Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0484"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "Maian Cart",
          "vendor": "Maianscriptworld",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "disclosure via Fulldisclosure"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "0day Rubbish Research Team is publicly disclosing a vulnerability in Maian\nCart 3.8, the self-hosted PHP shopping-cart system from Maian Media (Maian\nScript World), verified end to end against a real installation of that\nversion.\n\nType: unrestricted upload of a file with a dangerous type (CWE-434), realized\nas OS command execution (CWE-78) through an attacker-supplied PHP webshell,\nwith CWE-269 bearing on the execution privilege context. The Store Banners\npage of the administration backend (route /admin/index.php?p=settings\u0026s=9)\ndispatches multipart uploads to addBanners() in\nadmin/control/classes/class.system.php:376-413, which reads the raw client\nfilename at line 386, derives the stored extension from it at line 392 with\nstrrchr on the lower-cased name, composes the stored name at line 393 as the\nbanner prefix plus a counter from the banners table plus that extension, and\nwrites the file with move_uploaded_file at line 401, a second call site being\nrecorded at line 410. There is no extension allow-list, no MIME or finfo\nvalidation and no getimagesize() content check anywhere on the path;\nmc_safeImport at line 377 is an SQL-escaping pass over $_POST and never\ntouches $_FILES, and is_uploaded_file only confirms the file arrived over\nHTTP. With the shipped defaults RENAME_BANNERS=1 and BANNER_PREFIX=\u0027img_\u0027,\nan upload named shell.php is stored as img_1.php: the rename regenerates the\nbase name and preserves the attacker\u0027s extension. The destination,\ncontent/_theme_default/images/banners/, is inside the document root and\ncarries no deny rule, in explicit contrast to admin/import/.htaccess,\nadmin/attachments/.htaccess and content/_theme_default/cache/.htaccess, all\nof which ship Deny from all, so a plain GET for the stored img_\u003cid\u003e.php is\nhanded to the PHP interpreter and a one-line shell_exec webshell yields\ncommand execution in the web server process context. move_uploaded_file runs\nbefore the INSERT INTO banners statement, so the shell survives even a failing\nINSERT. The product\u0027s own image allow-list ($imgAllow at class.products.php:9,\napplied at :1213 and :1907 in addAdditionalProductPictures) is the one-line\ncontrol this handler omits.\n\nScoring. Four readings are published with their vectors, labelled, rather than\none number:\n- PRIMARY, and the only classification this advisory claims: 7.2 High,\n  CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. The sink sits behind the\n  webmaster gate at admin/control/system-load.php:79\n  (mc_isWebmasterLoggedIn, whose underlying test at functions.php:324-336\n  requires a fully populated webmaster session array).\n- CONDITIONAL, 9.8 Critical, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H,\n  for a deployment that retains an unchanged, known or guessable\n  administrator credential. This reading is this advisory\u0027s own construction,\n  not a figure produced by the research record, which scores the finding only\n  under the 7.2 vector and records that the unauthenticated objective was not\n  reached. It describes deployment state rather than product state: the\n  product ships no fixed factory credential, the install wizard writes the\n  operator-chosen USERNAME and PASSWORD into access.php, and no installation\n  whose credentials were guessable was verified. Its sole basis is the\n  companion observation that the installer-provisioned credential is never\n  forced to rotate (a CWE-798-class note about persistent provisioned\n  credentials without a rotation gate). It does not change the primary\n  classification.\n- CONSIDERED AND NOT ADOPTED: 8.8 High,\n  CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, which differs from the\n  primary vector only in Privileges Required and was not adopted because no\n  role below webmaster reaches the settings module in the recorded gate\n  model; and 9.1 High,\n  CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H, which would require Scope\n  Changed and does not fit, the vulnerable component and the impacted\n  component being the same security authority.\n\nAuthentication: administrator session. The login handler\n(admin/control/modules/system/portal.php:26-47) requires process=1, a cs_rf\nCSRF token matching the hidden field served on the login page, a user value\nequal to the USERNAME constant in access.php and a password verified through\nmc_PassHash; the trigger is isset($_POST[\u0027process_banners\u0027]) at\nsettings.php:84-87. The unauthenticated objective was pursued and exhaustively\nruled out: ajax.php exposes no file-write or command primitive an\nunauthenticated caller can steer; forging the persistent administrator cookie\nis infeasible because mc_encrypt(SECRET_KEY . DB_NAME) requires the\nper-installation database name, which is not remotely discoverable; the only\ngadget found was PHPMailer\u0027s __destruct, not exploitable into a dangerous sink\nin this codebase, so no object-population chain exists; the login path is not\ninjectable; and every move_uploaded_file call site identified sits under the\ngated /admin/ backend. No unauthenticated route to the sink is claimed.\n\nImpact: arbitrary OS command execution as the web server process, uid=0(root)\nin the laboratory capture because the test web tier ran as root, typically\nwww-data or apache in production. Full read and write access to store source\ncode, application configuration including the database credentials the\napplication itself reads, uploaded order attachments and the surrounding file\nsystem; database access with the application\u0027s own privileges, meaning the\nstore\u0027s orders, customer records and settings; persistence, since the stored\nimg_\u003cid\u003e.php outlives the administrator session and nothing in the product\nscans for or removes it; and a pivot into whatever segments the store host can\nreach. For an insider or credential-holder the upload is audit-invisible: it\nappears in the interface as an ordinary banner addition.\n\nVerification boundary, stated plainly. Verified end to end against a real Maian\nCart 3.8 installation: the product\u0027s own install wizard run to completion on a\nLinux laboratory host, creating 62 database tables and populating the settings\nrows, with MySQL 8.0.46 on a dedicated laboratory schema and account, and the\nweb tier being the PHP built-in server bound to loopback for laboratory\nsafety. That process ran as root for the session in question, which is why\nuid=0(root) was observed and why the stored 39-byte shell, exactly the length\nof the one-line payload, was owned by root. Three independent runs reached\ncommand execution, the third being a from-scratch re-analysis pass by an\nindependent reviewer who rebuilt the audit and shipped a second, distinctly\nnamed shell through the same handler, stored as img_3.php. An adversarial\nrefutation review searched for a global upload sanitizer, a deny rule for the\nbanners directory, FilesMatch restrictions on .php, getimagesize usage on this\npath, web-server configuration hardening and install-time hardening, found\nnone, and left the finding standing. No vendor-hosted or third-party\ninstallation was touched, and no post-exploitation was performed beyond\nidentity and file-system probes.\n\nWhat was not exercised: the production Apache and mod_php stack was not run,\nso execution under Apache rests on static evidence plus the research record\u0027s\nown assertion that Apache with mod_php is the default production deployment,\nan assertion not substantiated from a vendor document; a non-root process\nidentity was not demonstrated, so the claim is command execution at whatever\nidentity the web server holds; the updateBanners edit path, the\nTRADE_THEME_FOLDER branch and the dead-code uploadWebLogo variant\n(class.system.php:956, same pattern, no call site, excluded from the finding)\nwere not exercised; only 3.8 was tested. One precondition is unresolved and\nstated rather than smoothed over: the banners directory must already exist on\ndisk. It was absent in the first laboratory iteration, move_uploaded_file\nfailed with a no-such-file-or-directory error, and the directory was created\nmanually before a later iteration succeeded; move_uploaded_file does not\ncreate directories and the handler\u0027s only filesystem guard tests the\ndestination file, not the directory. No artifact establishes which product\ncomponent creates it, so no first-upload directory creation is claimed.\n\nRelated product, scoped out. The research record notes that the sibling Maian\nSupport product exhibits the same CWE-434-class pattern, a content tree\nwithout .htaccess protection combined with Apache AllowOverride All. That\nproduct is out of scope for this advisory: no exploitation attempt was made\nthere and no identifier is claimed for it.\n\nFix direction, in short: enforce an extension allow-list at the sink reusing\nthe control already in class.products.php; validate uploaded content with\ngetimagesize() or finfo; discard the client-supplied extension and name stored\nfiles server-side; make the banner storage non-executable by moving it outside\nthe document root or shipping a deny rule plus documented nginx-equivalent\nguidance; route every move_uploaded_file call site through one shared\nvalidator; force first-login rotation of the installer-provisioned\nadministrator credential; and remove or gate the dead uploadWebLogo code.\n\nFull technical analysis and a reproducible proof-of-concept:\n  https://0day-rubbish.com/blog/maian-cart-addbanners-upload-extension-webshell-rce\n\nProject archive (ongoing disclosure series):\n  https://github.com/Exploit-Garbage/0day-Rubbish\n\nThe vendor has been notified through the support mailbox it publishes for its\nproducts. No vulnerability identifier has been assigned to this finding yet.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-269",
              "description": "CWE-269",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-434",
              "description": "CWE-434",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-78",
              "description": "CWE-78",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-798",
              "description": "CWE-798",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-11-02T07:30:01Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/6"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Oct/6"
        },
        {
          "url": "https://0day-rubbish.com"
        },
        {
          "url": "https://0day-rubbish.com/blog/maian-cart-addbanners-upload-extension-webshell-rce"
        },
        {
          "url": "https://github.com/Exploit-Garbage/0day-Rubbish"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Oct/6"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "[0day-rubbish] Maian Cart 3.8 addBanners unrestricted banner upload to PHP webshell and administrator command execution (7.2 primary, PR:H)",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0469",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/6",
            "automated": true,
            "contentSha256": "996730e626ea94faa931788cc5994301981a5d0a11716f9aa25f9688cf48c3e0",
            "evidenceScore": 11,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Oct/6",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-10-05T17:53:29Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-11-02T07:30:01Z",
    "dateUpdated": "2026-11-02T07:30:01Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0469"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "Advantech Webaccess Node",
          "vendor": "N/A",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "disclosure via Fulldisclosure"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "0day Rubbish Research Team is publicly disclosing a vulnerability in Advantech\nWebAccess Node 9.2.3, the closed-source industrial SCADA/HMI web server from\nAdvantech (Taiwan).\n\nType: unrestricted file upload (CWE-434) compounded by path traversal (CWE-22), on\na page that performs no authorization decision at all (CWE-306). CWE-73 and CWE-862\nalso map; CWE-250/CWE-269 apply conditionally where the pool runs at high\nprivilege. In the WaCrpt ASP.NET Web Forms application served under\n/broadweb/WaCrpt/, the fileSubmit_Click handler in bin\\WaCrpt.dll concatenates two\nattacker-supplied form fields into\nServer.MapPath(\"~/report/\" + projName + \"_\" + nodeName + \"/\"), gates the result on\nnothing but Directory.Exists(rptDirPath), then calls FileUpload1.SaveAs(filePath)\nwith no extension validation - and does so before it attempts to open the file as a\nCrystal Report. Reordering those two calls alone would break the chain.\n\nThe traversal rides in nodeName rather than in the uploaded filename, because\nASP.NET already strips any client-side directory from the multipart filename.\nSending nodeName = \\..\\..\\ normalises the destination to the WaCrpt application\nroot, a directory that always exists, so the provisioning check is satisfied with no\nreport project created and no report directory present; ASP.NET request validation\ninspects for HTML-dangerous sequences and not for backslash or dot-dot, so nothing\nfilters it. The bound is exactly two dot-dot levels - three or more are refused with\nHttpException \"Cannot use a leading .. to exit above the top directory\".\n\nThe chain is three HTTP requests plus a follow-on GET. Request 1 harvests\n__VIEWSTATE (1056 bytes) and __EVENTVALIDATION (92 bytes) while establishing the\ntraversed destination. Request 2 posts a 510-byte ASP.NET page as FileUpload1 with\nfileSubmit=Upload; SaveAs writes it into the application root, ReportDocument.Load\nthen throws and the server returns HTTP 500 - a red herring, since the write already\ncompleted. Request 3 GETs the written page, which the build manager compiles on first\nrequest and executes inside w3wp.exe, running cmd.exe /c with captured stdout. No\ncredentials, no user interaction, no race window, no memory corruption, no prior\nserver state. A User-Agent header is mandatory: without one the CrystalDecisions\nviewer control throws a NullReferenceException, the form never renders and the chain\nstalls at step 1 - a trap that makes an unaffected conclusion easy to reach wrongly.\n\nAuthentication. No authorization decision exists anywhere in the application, and\nthat half is artifact-proven: Page_Load performs no session, cookie, token or\nprincipal check and carries no auth filter, and its failure branch is a\nResponse.Redirect to the login page - a navigation aid, not an access denial. The\nshipped WaCrpt Web.config declares an authentication mode but has no authorization\ndeny rule and no custom authentication module; there is no global.asax in the\ndirectory; eight sibling files in the module call a session-existence check and\nCrystalRpt.cs is not among them. The omission signature is decisive: addTemplate.cs,\nthe SECOND report-upload handler in the same module, enforces a case-insensitive\n.RPT comparison while CrystalRpt.cs enforces nothing. The product has a working\nmechanism - waconfig90 controllers carry an auth filter with session plus csrfToken\nvalidation - and this page is not enrolled in it.\n\nThe one gap, stated as a gap: whether IIS delivers an anonymous request to the\nWaCrpt application path lives in the site\u0027s applicationHost.config, and no such\nexcerpt, no installer-authored IIS fragment and no vendor documentation of that\nfactory setting was obtained. PR:N is published on a structural argument plus lab\nreproduction, not on an extracted artifact - the product\u0027s own operator login page\ncannot function unless the hosting site accepts anonymous requests, and it is served\nby the same IIS site. An administrator who disabled anonymous authentication on that\npath, or fronted it with an authenticating gateway, is not exposed on this vector,\nand the conditional score below prices exactly that.\n\nScoring. All three readings the analysis priced are published:\n- PRIMARY, 9.8 Critical, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\n- CONDITIONAL, 8.8 High, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, applying\n  where IIS authentication is enforced on the WaCrpt application path or an\n  authenticating gateway fronts it; nothing else in the finding changes.\n- REJECTED, 8.1 High, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, considered\n  because the traversal depth and the mandatory User-Agent are non-obvious and\n  rejected because both are fixed constants under the attacker\u0027s control, which is\n  not the CVSS 3.1 meaning of AC:H.\nScope is Unchanged deliberately: the compromise executes as the pool identity of the\nvulnerable product\u0027s own web application, so the gain crosses a privilege level, not\na component\u0027s security scope. S:C on the same impact values would compute to 10.0\nand is not claimed.\n\nOn scoring accuracy: the primary vector computes to ISS 0.914816, Impact under S:U of\n5.873119, Exploitability 3.887043 and base 9.760161495, which the CVSS 3.1 Roundup\nrule renders as 9.8. The figure the research record carried for this finding is the\nfigure its own vector computes, so no correction was required. We say so because\nseveral earlier advisories in this repository carried recorded scores that did not\ncompute for their recorded vectors; those are being recomputed rather than copied.\n\nImpact. Confidentiality High: full read of the product\u0027s configuration, the SCADA\nproject tree it serves and database connection material - these nodes routinely hold\nthe point list, alarm configuration and historian data for the monitored process.\nIntegrity High: a generic write primitive placing an attacker-named file with\nattacker-chosen content into a served, script-executing directory, plus arbitrary\ncommand execution, making product binaries, configuration, the report tree, tag and\nalarm data and host state modifiable; manipulation of served HMI content, tag values\nand alarm thresholds is why this is an operational-technology incident and not only\na web-application one. Availability High: the web tier, the SCADA runtime it fronts\nand the host can be stopped or corrupted, removing operator visibility of the\nmonitored process even where the controlled process keeps running.\n\nExecution identity caveat. The verified identity was nt authority\\system with\nSeTcbPrivilege, SeDebugPrivilege, SeImpersonatePrivilege and SeBackupPrivilege\nenabled - the full SYSTEM set - but that was the VERIFICATION application pool,\nconfigured in the lab as LocalSystem. No shipped pool identity is asserted: the\ninstaller binds broadweb to DefaultAppPool and a separate helper writes the pool\u0027s\nIdentityType at install time, a value that could not be resolved from static\nstrings. The rating does not depend on it, since C:H/I:H/A:H are assessed on the\ncode-execution primitive itself.\n\nRelationship to previously published work. A previously published advisory covers an\nunrestricted file upload on this product scored 8.8 with\nAV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H - PR:L, an authenticated caller - affecting\n9.2.1 with a fix in 9.2.2, and it does not name the affected endpoint. This finding\nis PR:N, and the unvalidated sink was confirmed by decompilation in 9.2.3, after that\nfix. Two readings are consistent with the evidence and the advisory does not pretend\nto settle between them: either the earlier fix addressed a different upload path and\nCrystalRpt.aspx was never covered, making this an independent unauthenticated\nvariant, or the fix did not close the unauthenticated route into the same code,\nmaking this an incomplete-fix variant. Without a byte-level diff between 9.2.2 and\n9.2.3, overlap cannot be excluded to certainty, and the advisory says so rather than\nclaiming more novelty than the evidence carries.\n\nVerification boundary, stated plainly. Everything dynamic was produced by deploying\nthe shipped WaCrpt application - CrystalRpt.aspx (2381 bytes), Web.config and\nbin\\WaCrpt.dll, the shipped files as documented in the research record, used without\nmodification - into a real IIS site and driving it over HTTP on loopback. The whole\nrequest path is genuine: IIS request handling, the Web Forms pipeline, event\ndispatch into fileSubmit_Click, Server.MapPath normalisation, FileUpload.SaveAs, the\nbuild manager compiling a freshly written page and process creation in w3wp.exe.\n\nA complete default installation of WebAccess Node 9.2.3 was NOT achieved: the 1.9 GB\nself-extracting installer hung in Session 0 and never produced a stock,\nvendor-configured deployment, so the test was surgical rather than end-to-end. Three\nconsequences are carried explicitly. First, the site configuration was authored in\nthe lab rather than read from the installer and the application was served at the\nsite root over loopback, so the /broadweb/WaCrpt/ prefix is derived from a literal\ninside the decompiled Page_Load - the Response.Redirect to\n/broadweb/user/signinonly.asp - plus the application\u0027s placement in the\ndistribution, and is strong inference rather than an observed request against a stock\ninstall. Second, the SYSTEM identity was the lab pool\u0027s; the shipped site binding,\nshipped pool identity and interaction with the rest of the product were never\nobserved at runtime. Third, the record documents the installer and its size and an\nunpacked deployment archive holding those files and asserts they are the real\nproduct\u0027s, but does not log the extraction step, so no end-to-end provenance chain is\nclaimed - what is asserted is that nothing in them was altered for the test. Three\naccommodations modified the hosting environment, not the vulnerable code:\nCrystalDecisions assembly redirects to match the lab host\u0027s GAC, a log4net copy from\nthe legacy GAC_32 location, and the LocalSystem pool identity.\n\nAlso not exercised: no interaction with the rest of the product; no network-path\ntest, every request having traversed loopback from one Windows host with no\nfirewall, reverse proxy, WAF or TLS terminator in between; no GET-only variant of\nrequest 1; no overwrite test, no non-page payload and no persistence test; no\nprivilege enumeration under a restricted pool.\n\nWhat is nevertheless established at strength: two independent client implementations\nwith two independently written payloads of different sizes (510 and 450 bytes) and\ndifferent leaf names produced the same result, corroborated from the target\nfilesystem and the IIS W3C log rather than from client responses alone - the written\npage sat in the application root at exactly 510 bytes, byte-identical to what was\ntransmitted, with an on-disk timestamp matching the logged POST, and the log shows\nthe two POSTs returning 200 then 500 immediately followed by a 200 for the uploaded\nfile. An attacker-chosen marker was echoed and a second, unrelated binary invoked on\nthe same command line. An independent adversarial review attacked the chain from\nseven angles and did not refute it; only the execution-identity angle returned\npartially confirmed. A separate re-analysis pass over the same decompiled sources\nindependently returned CONFIRMED.\n\nAlso recorded in the advisory, from the same exhaustion pass over the web tier: a\ngenuine SQL injection in the unauthenticated /Login operation of the product\u0027s WCF\nmobile service, which does NOT escalate to code execution because that path\u0027s\nbackend is a Microsoft Access .mdb offering no xp_cmdshell or comparable\nOLE-automation primitive, and the SQL Server SQLEXPRESS instance elsewhere in the\nproduct is not reached from it.\n\nAffected-version statement: 9.2.3 is the only release whose binaries were decompiled\nand exercised; other versions were not enumerated and no cross-version byte\ncomparison was performed. Validate your own build.\n\nRemediation is set out in the advisory in priority order and reduces to: validate\nthe extensio"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-22",
              "description": "CWE-22",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-250",
              "description": "CWE-250",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-269",
              "description": "CWE-269",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-306",
              "description": "CWE-306",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-434",
              "description": "CWE-434",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-73",
              "description": "CWE-73",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-862",
              "description": "CWE-862",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-11-02T07:30:00Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/2"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Oct/2"
        },
        {
          "url": "https://0day-rubbish.com"
        },
        {
          "url": "https://0day-rubbish.com/blog/advantech-webaccess-crystalrpt-unauth-file-upload-rce"
        },
        {
          "url": "https://github.com/Exploit-Garbage/0day-Rubbish"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Oct/2"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "[0day-rubbish] Advantech WebAccess Node 9.2.3 unauthenticated CrystalRpt.aspx file upload and path traversal to code execution in w3wp.exe (9.8)",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0465",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/2",
            "automated": true,
            "contentSha256": "5c8055491691e87037814c975bf7716eb7f5af66a1d419f25cf299769481a80d",
            "evidenceScore": 11,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Oct/2",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-10-05T17:52:23Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-11-02T07:30:00Z",
    "dateUpdated": "2026-11-02T07:30:00Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0465"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "SCADA",
          "vendor": "Lcds Laquis",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "disclosure via Fulldisclosure"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "0day Rubbish Research Team is publicly disclosing a vulnerability in\nLCDS Laquis SCADA.\n\nType: Unauthenticated /uploade.html file write chained with CMDEXT*.DLL autoload (CWE-434)\nCVSS: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)\nImpact: arbitrary native code execution inside the SCADA web and HMI process, which also hosts the Modbus TCP listener\nAuthentication: unauthenticated (no password configured is the default)\n\nFull technical analysis and a reproducible proof-of-concept:\n  https://0day-rubbish.com/blog/lcds-laquis-scada-unauth-uploade-cmdext-dll-rce\n\nProject archive (ongoing disclosure series):\n  https://github.com/Exploit-Garbage/0day-Rubbish\n\nVendor has been notified. CVE ID is pending.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-434",
              "description": "CWE-434",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-02T04:57:32Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/51"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Sep/51"
        },
        {
          "url": "https://0day-rubbish.com"
        },
        {
          "url": "https://0day-rubbish.com/blog/lcds-laquis-scada-unauth-uploade-cmdext-dll-rce"
        },
        {
          "url": "https://github.com/Exploit-Garbage/0day-Rubbish"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Sep/51"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "[0day-rubbish] LCDS Laquis SCADA Unauthenticated /uploade.html file write chained with CMDEXT*.DLL autoload (9.8)",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0409",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/51",
            "automated": true,
            "contentSha256": "f49df1a20f93abd04032c394ef7b18848a7a86bccf8a10960e47b717f37b4b3e",
            "evidenceScore": 10,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Sep/51",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-09-20T12:18:26Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-10-02T04:57:32Z",
    "dateUpdated": "2026-10-02T04:57:32Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0409"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "Codoforum",
          "vendor": "Codoforum",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "disclosure via Fulldisclosure"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "0day Rubbish Research Team is publicly disclosing a vulnerability in Codoforum 5.4.1.\n\nType: Authenticated arbitrary file upload to PHP RCE (CWE-434)\nCVSS: 7.2 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)\nImpact: Arbitrary PHP code execution as www-data: the forum database, user data, and application files under attacker \ncontrol, commonly escalating to the underlying host.\nAuthentication: authenticated (requires valid session)\n\nFull technical analysis and a reproducible proof-of-concept:\n  https://0day-rubbish.com/blog/codoforum-admin-cat-img-polyglot-upload-rce\n\nProject archive (ongoing disclosure series):\n  https://github.com/Exploit-Garbage/0day-Rubbish\n\nVendor has been notified. CVE ID is pending.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-434",
              "description": "CWE-434",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-11T08:15:56Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/2"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Sep/2"
        },
        {
          "url": "https://0day-rubbish.com"
        },
        {
          "url": "https://0day-rubbish.com/blog/codoforum-admin-cat-img-polyglot-upload-rce"
        },
        {
          "url": "https://github.com/Exploit-Garbage/0day-Rubbish"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Sep/2"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "[0day-rubbish] Codoforum 5.4.1 Authenticated arbitrary file upload to PHP RCE (7.2)",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0162",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/2",
            "automated": true,
            "contentSha256": "976a662da445b62be07b0c57b190259f77f56ebd75846ddc37273f4e819db39e",
            "evidenceScore": 11,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Sep/2",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-08-31T15:10:08Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-09-07T13:35:56Z",
    "dateUpdated": "2026-09-11T08:15:56Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0162"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}