CVE Request for Webform Multiple File

Created on 23 May 2025, 2 months ago

CVE Request

I'm attaching my assessment of Vulnogram json file for:

[D7ES] XSS vulnerability on the file name renderer
https://security.drupal.org/node/162249

I used CVSS 4.0 because Vulnogram labels 3.1 as obsolete (though I'm not sure Drupal is ready for CVSS, per another issue I read).

In the assessment I presumed that a web form could be opened up to an unauthenticated user who could upload a malicious file, thus leading to a rating of High/7.

Vector string
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N/S:N/R:U/V:D/RE:L/U:Amber

Happy to make revisions.

💬 Support request
Status

Active

Version

1.0

Component

Code

Created by

🇺🇸United States aangel

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @aangel
  • 🇺🇸United States aangel
  • 🇺🇸United States greggles Denver, Colorado, USA

    Thanks aangel. Moving status. And let's give this a few days for review.

  • 🇮🇹Italy bigbabert Milano, Italy

    Hi why there is link to security private issue? should not remain private? https://security.drupal.org/node/162249

  • 🇺🇸United States cmlara

    Question:
    It appears from the description the vulnerability was in a 3rd party product that was copied into the the module.

    Would the module hosted on D.O. actually be the supplier of the vulnerable product in this case?

    Would section 4.3 of the CNA v4.1.0 rules come into play here?

    4.3.2 If a CNA is considering an assignment, and the CNA is not the Supplier of the vulnerable Product, then the CNA SHOULD make a reasonable and good faith effort to notify the Supplier. For example, if an operating system Supplier discovers a Vulnerability in a library from an upstream Supplier, in addition to assigning the CVE ID to the upstream Vulnerability, the operating system Supplier SHOULD attempt to notify the upstream library Supplier. This reduces duplicate CVE ID assignments and helps alert others that may be affected by the Vulnerability.

    This is an interesting grey area, I'm not 100% sure on this one way or the other, bringing this up for discussion since Drupal actively publishing CVE's is a relatively new development and the procedures appear to be still being developed.

  • 🇺🇸United States greggles Denver, Colorado, USA

    @cmlara thanks for that question and pasting the documentation. Are you interested in contacting the upstream maintainer there?

    Or is anyone else interested in doing that? Since the forked code was/is distributed from drupal.org it seems we could issue a CVE if the upstream maintainer is not interested in doing that.

  • 🇺🇸United States cmlara

    My apologies, I had thought I had submitted my response on this issue previously.

    Are you interested in contacting the upstream maintainer there

    My entire knowledge of this reported vulnerability is based off the vulnogram, ideally someone who knows more or has been involved in working on the repair to the Webform Multi File Upload module would do so as they would likely be better informed.

    it seems we could issue a CVE if the upstream maintainer is not interested in doing that

    .

    Possibly there are other parts of the CNA rules to consider as well:

    4.2.1.1 The CNA with the most appropriate scope MUST be contacted and given the first opportunity to assign.

    4.2.1.2 also comes into play that if the most appropriate scope refuses the Root CNA must make a determination and direct a CNA to issue.

    then an appropriate Root MUST make a Vulnerability determination. If the Root determines that one or more Vulnerabilities exist, the Root MUST direct a CNA-LR or another CNA with appropriate scope to assign as quickly as possible and no later than 72 hours after becoming aware of the first refusal.
    

    Question is, who is most appropriate scope?

    4.2.2.1.3 scope determination is relevant to review.
    Drupal.org CNA scope is “All projects hosted under drupal.org, including End of Life (EOL) code.”

    What is the interpretation of hosted? Is it being the official development platform, or is redistributing also hosting?
    How integrated is the code in the Drupal module (is it line for line, or is it a fork that deviated some time in the past and could legitimately called its own project)?
    Is there another CNA with better scope?

    I’ll note the goal behind the process is that for any single vulnerability there is only a single CVE to refer to it no matter who re-distributes the code and that any program that contains the flaw references that CVE. All of the above questions are above my current knowledge on the module and how the code was distributed.

  • 🇺🇸United States greggles Denver, Colorado, USA

    OK. I posted https://github.com/fyneworks/multifile/issues/113

    Leaving this at "needs review" for feedback on the CVE content although probably "postponed" would be appropriate since we're waiting here on action in that Github project before taking action here.

  • 🇺🇸United States greggles Denver, Colorado, USA

    It's been 2 weeks since that was posted. Is there a timeline before the next action? What is the appropriate next action?

    @aangel can you help answer these questions?

    What is the interpretation of hosted? Is it being the official development platform, or is redistributing also hosting?
    How integrated is the code in the Drupal module (is it line for line, or is it a fork that deviated some time in the past and could legitimately called its own project)?
    Is there another CNA with better scope?

  • 🇺🇸United States damienmckenna NH, USA

    IMHO:
    * If the module's copy of the JS library did involve changes, ie has become a fork thus its own project, then it should get its own CVE.
    * If the module's copy of the JS library did not involve additional changes then it should defer to a CVE being generated for the 3rd party library and then the Drupal project refer to it.

    Once we can iron this out I think we should document it to make future CVEs quicker to do.

  • 🇺🇸United States cmlara

    What is the interpretation of hosted? Is it being the official development platform, or is redistributing also hosting?

    As this is a CNA policy the Drupal CNA should provide formal feedback on this. While reporters and security analysts can provide our opinion on this statement ultimately the Drupal CNA created that restriction and should be able to provide a formal definition.

  • 🇺🇸United States greggles Denver, Colorado, USA

    As one of a very small number of volunteers handling a lot of CVE topics, I rely on feedback from a variety of sources to help.

    I see the Drupal module shipped with what seems to be the 1.4.7 version of the multifile code. I can't find the reference copy of that file online in Google Code repositories. Is anyone able to find a reference copy so we can compare it?

  • 🇺🇸United States cmlara

    Attached is R40 taken from the Google Code repo.svndump.gz.

    Note R43 also had the same header with modified content however that revision does not match the sample on D.O.

    There does appear to be a whitespace and encoding difference (diff -b required) however otherwise the report returns no. difference.

  • 🇺🇸United States greggles Denver, Colorado, USA

    Thanks for that research, cmlara!

    I've read the CVE rules a bit more.

    I think Drupal could issue a CVE since the code owner has not responded on the issue I created in #8 and since this code is also distributed from drupal.org (putting it in our scope as a CNA).

    I also think @aangel could go to a CNA-LR to get a CVE for this.

    I don't have a strong feeling of which one is the right action.

Production build 0.71.5 2024