Google are introducing virtual credit cards to the Chrome browser for users of their services in the US. We take a look at what's in store.
The post Virtual credit cards coming to Chrome: What you need to know appeared first on Malwarebytes Labs.

When you’re buying things online, reducing the exposure of payment details during transactions is one way to help reduce the risk of data theft. If you can _hide_ this payment data and switch it out for something else entirely, even better.

Google is proposing to do just that for customers in the US, with recently announced plans to offer a virtual credit card service for Chrome.

**What is a virtual credit card?**

The concept of virtual credit cards has been around for some time now. But with Google proposing to start using virtual credit cards, more people are likely to start talking about them.

Have you ever used a disposable email alias, or a VoIP service which displays a number of your choosing? These are ways you can keep your most personal information safe from prying eyes. Going one step further, it can be a valuable tool to pin down who’s had a breach, and who voluntarily leaks your data. If you create an email alias for every service you use, you’ll know the moment something has happened if the alias shows up in a dump or you receive spam on it.

Virtual credit card numbers share a few of these traits. Your actual card number never goes online. In its place is a variety of virtual numbers generated by your card provider connected to your account. These numbers may well expire at a set period in the future like real ones, so you don’t have to worry about an ever-increasing set of virtual details gathering dust in the corner.

Years ago, when I first started going to security conferences overseas, my bank card wasn’t accepted in most of the cities I visited. A stop-gap solution to this was someone buying me a bunch of pre-paid credit cards. This helped keep my real card safe. Virtual cards are like a _significantly_ more advanced version of pre-pay efforts. When I used them, some pre-paid cards had a cap on funds allocated so you had to buy several at a time, and they also expired if you didn’t use the money within a certain time period.

Good news: You don’t have to worry about _any_ of this with a virtual card number.

**What is Chrome offering to US based users?**

Here’s what Google has to say on the subject:

> _As people do more shopping online, keeping payment information safe and secure is critically important. We’re launching virtual cards on Chrome and Android. When you use autofill to enter your payment details at checkout, virtual cards will add an additional layer of security by replacing your actual card number with a distinct, virtual number. This eliminates the need to manually enter card details like the CVV at checkout, and they’re easy to manage at pay.google.com — where you can enable the feature for eligible cards, access your virtual card number, and see recent virtual card transactions. Virtual cards will be rolling out in the US for Visa, American Express, Mastercard and all Capital One cards starting this summer._

According to TechCrunch, Google “will not use any of this information for ad targeting purposes”. It remains to be seen if or when this rollout will extend to regions outside of the US.

**Keeping you safe, and saving you time**

The aim of the game is to make it harder for fraudsters to obtain your genuine details. Losing your card data to a skimming attack on a hijacked site or having it swiped from a database is a huge pain. Phonecalls and cancelled cards await.

I myself have had credit card details compromised. To this day, I have no idea how or where it happened. I only know that it involved a spectacular amount of wine. It happened during a rather complicated long distance house move, and having to sink time into calling fraud teams, cancelling the card I really could have done with for the move, and having a replacement card almost sent to the wrong address by mistake was really not great.

Yet these are the additional complications any sort of compromise routinely throw up. It’s never “just” the card details. If I’d had a virtual card number when the great wine heist of 2016 had taken place, it wouldn’t have mattered at all. I could have just switched to a new virtual number and be done. No card replacement required.

**Tightening the grip on bogus transactions**

Banks are increasingly ramping up checks made when trying to buy items online. Seeing a Verified by Visa popup, or a request to use an authenticator device, is fairly common. These tactics appear to be working. One bank reported 2,000 fewer cases of card fraud per month after the introduction of new payment checks.

Elsewhere, Apple Pay is serious about enhancing fraud prevention features. Location specific features (should you have them enabled) will help shut down rogue payment attempts.

A recent report claims card fraud losses could hit around $408.50 billion globally over the next decade. These are huge numbers to contend with. We’re going to need every tool available to chip away at that number. Whether you’re using virtual numbers, pre-loaded cards, or another method altogether for real world payments, having so many options available can only be a good thing.

Virtual credit cards coming to Chrome: What you need to know

Attack technique bypasses email filters and burnishes credibility of phishing links

Attack technique bypasses email filters and burnishes credibility of phishing links

A failure to validate subdomains within so-called ‘vanity URLs’ by Box, Zoom, and Google Docs created a powerful way to enhance their phishing campaigns, security researchers have revealed.

Vanity URLs can be customized to include a brand name and a description of the link’s purpose (for example, brandname/registernow) and typically redirect to a longer, generic URL.

Widely used by software-as-a-service (SaaS) applications, vanity URLs are used to share or request files, invite users to register for events, and so on.

**False sense of security**

The vulnerabilities discovered in Box, Zoom, and Google Docs enable attackers to abuse the apparent reassurance vanity URLs offer recipients that they are dealing with a legitimate organization rather than cybercriminals.

Researchers from Varonis Threat Labs found that the SaaS applications validated vanity URLs’ URI (the unique sequence of characters at the end of the link), but not its descriptive subdomain (the portion preceding the URI).

Read more of the latest phishing news and attacks

“As a result, threat actors can use their own SaaS accounts to generate links to malicious content (files, folders, landing pages, forms, etc.) that appears to be hosted by your company’s sanctioned SaaS account,” reads a blog post published by Varonis Threat Labs.

“Achieving this is as easy as changing the subdomain in the link.”

**Hit rate**

This attack technique, as demonstrated in this video, would act to massively boost the success rate of phishing or malware distribution campaigns, according to Varonis CMO Rob Sobers.

“It can make a massive difference because spoofed links appear legitimate to security technologies like email filters and CASBs (Cloud Access Security Broker\],” Sobers told The Daily Swig.

“They would normally block a faked or misspelled URL (like apple-support.zoom.us). In this case, since we’re spoofing the REAL URL, there’s no way for these types of technologies to automatically filter or flag the URL as malicious.”

Sobers continued: “Also, savvy users can typically pick up on subtle differences when loading a fake URL in their browser – things like an invalid security certificate or misspelled subdomain. With this abuse, the URL and certificate are completely valid.”

Since three of the most widely used SaaS apps containing the same flaw, “it’s very likely that similar issues exist in other SaaS apps”, warned Sobers.

**Tell-tale signs**

Box, the popular cloud content management app, patched flaws affecting vanity URLs for file-sharing and public forms used to request files and associated information.

The file-sharing issue was exacerbated by an attacker’s ability to add password protection to malicious files and upload a targeted brand’s logo and recreate its color scheme, while the absence of branding on public forms makes it harder for victims to spot tell-tale design flaws.

A spokesperson from Zoom told The Daily Swig that it had addressed the potential abuse of vanity URLs for meeting recordings and webinar registration pages “by warning users if they are being redirected to a different subdomain”.

However, Varonis urged users to be “cautious when accessing branded Zoom links” given that “users often click through non-critical warning messages”.

Attackers could also brand a Google Form requesting sensitive confidential data with targeted company’s logo as yourcompanydomain.docs.google.com/forms/d/e/:form\_id/viewform.

“The form could require registering with an email from your company domain, making it seem more trustworthy,” said Varonis.

Google Doc documents exchanged via the ‘publish to web’ feature are similarly vulnerable.

Google is yet to roll out a fix, according to Varonis.

YOU MIGHT ALSO LIKE RuTube hack: Russian video platform denies loss of source code following cyber-attack

Box, Zoom, Google Docs offer phishing boost with ‘vanity URL’ flaws

Google on Wednesday took to its annual developer conference to announce a host of privacy and security updates, including support for virtual credit cards on Android and Chrome.
"When you use autofill to enter your payment details at checkout, virtual cards will add an additional layer of security by replacing your actual card number with a distinct, virtual number," Google's Jen Fitzpatrick

Google on Wednesday took to its annual developer conference to announce a host of privacy and security updates, including support for virtual credit cards on Android and Chrome.

"When you use autofill to enter your payment details at checkout, virtual cards will add an additional layer of security by replacing your actual card number with a distinct, virtual number," Google's Jen Fitzpatrick said in a statement.

The goal, the search giant, said to keep payment information safe and secure during online shopping and protect users from skimming attacks wherein threat actors inject malicious JavaScript code to plunder credit card numbers and sell them on the black market.

The feature is expected to roll out in the U.S. for Visa, American Express, Mastercard, and Capital One cards starting this summer.

Interestingly, while Apple offers an option to mask email addresses via Hide My Email, which enables users to create unique, random email addresses to use with apps and websites, it's yet to offer a similar option for creating virtual credit cards.

The development comes a week after Google, Apple, and Microsoft banded together to accelerate support for a common passwordless sign-in standard that allows "websites and apps to offer consistent, secure, and easy passwordless sign-ins to consumers across devices and platforms."

Additionally, Google said it's expanding phishing protections in Google Workspace to Docs, Slides and Sheets, and that it plans to debut a new "My Ad Center" later this year to give users more control over personalized ads on YouTube, Search, and Discover feed.

What's more, users would be able to request personally identifiable information such as email, phone number, or home address to be removed from search results through a new tool that will be accessible from the Google App.

Also coming is a new Account Safety Status setting that will "feature a simple yellow alert icon on your profile picture that will flag actions you should take to secure your account."

Other key privacy and security features unveiled at Google I/O 2022 include support for end-to-end encryption for group conversations in the Messages app for Android and the availability of on-device encryption for Google Password Manager.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Android and Chrome Users Can Soon Generate Virtual Credit Cards to Protect Real Ones

Sensitive Data Exposure Due To Insecure Storage Of Profile Image in GitHub repository polonel/trudesk prior to v1.2.1.

**Description**

When the user uploads his profile picture, the uploaded image’s EXIF Geolocation Data does not get stripped. As a result, anyone can get sensitive information of trudesk users like their Geolocation, their Device information like Device Name, Version, Software & Software version used, etc.

**Proof of Concept**

1.Browse this link:- https://github.com/ianare/exif-samples/blob/master/jpg/gps/DSCN0012.jpg

2.Download the image Upload the picture on your profile and click on save.

3.Now see the path of the uploaded image ( Either by right click on image then copy image address OR right-click, inspect the image, the URL will come in the inspect, edit it as HTML )

4.Then open:- http://exif.regex.info/exif.cgi

5.Then select the image and click on "View Image Data" now you can see the EXIF data.

**Video PoC:-**

https://drive.google.com/file/d/1\_-lUIFVpC0BrxrviLgO-Kythb-qaBt8a/view?usp=sharing

**Impact**

This vulnerability impacts all users on trudesk. This vulnerability violates the privacy of a User and shares sensitive information of the user who uploads their profile picture on trudesk.

CVE-2022-1044: Sensitive Data Exposure Due To Insecure Storage Of Profile Image in trudesk

Foxit PDF Reader and PDF Editor before 11.2.2 have a Type Confusion issue that causes a crash because of Unsigned32 mishandling during JavaScript execution.

CVE-2022-30557: Security Bulletins | Foxit Software

The technique, called store-now, decrypt later (SNDL), means organizations need to prepare now for post-quantum cryptography.

Although quantum computing is years away from commercial availability, business leaders, CIOs, and CISOs need to act now to prepare for the technology's inevitable ability to crack RSA-encrypted data. Failure to start adopting a post-quantum cryptography (PQC) strategy will put all existing encrypted data assets at risk of exposure, according to a stark warning from key technical cryptography experts issued on Wednesday.

A peer-reviewed paper chronicling that threat with a technical road map for transitioning to PQC appeared Wednesday in _Nature_, a leading journal for the science and technology communities.

The cybersecurity experts who wrote the paper, titled "Transitioning organizations to post-quantum cryptography," underscored the fact that when large and fault-tolerant (LFT) quantum computers become available, attackers will be able to use them to crack most existing public key crypto systems, including RSA and elliptic curve cryptography (ECC).

**SNDL Threat**

The paper points to three critical issues that the authors contend organizations must address. First is the existence of an active and critical threat called store-now, decrypt later (SNDL), a practice wherein attackers steal sensitive data and hold onto it with the intent of decrypting it once quantum computing becomes available.

Second, the authors warn that quantum computers will be able to break the most commonly relied on RSA and ECC to forge signatures. That would put at risk all SSL-based websites, zero-trust architectures, and cryptocurrencies, among other things, according to the authors.

And third, they highlight how the National Institute of Standards and Technology (NIST) is poised to select a set of PQC candidates that it will recommend as standards. Although the paper was written months ago before Wednesday's publication, NIST is poised to reveal the candidates within a few weeks and potentially sooner.

Dustin Moody, a NIST mathematician, confirmed the imminent announcement of the PQC algorithm candidates. Among cybersecurity standards, it is one of NIST's largest undertakings since developing Advanced Encryption Standard (AES) and Secure Hash Algorithm-3 (SHA-3). The new PQC standard will likely include more than one algorithm, Moody told Dark Reading.

"Security-wise, we want to make sure we're not putting all our eggs in one basket," Moody says. NIST is considering public key digital signatures as well as encryption or equivalently key establishment, Moody adds: "There will be at least one for each of these."

NIST's pending announcement was presaged by two directives last week from the Biden administration aimed at recognizing and addressing PQC.

**Impact on Existing Data Assets**

While the paper provides a detailed technical breakdown of PQC issues, it also aims to bring awareness of the implications of quantum computing for existing information assets and emphasize the need to develop a plan.

"For those organizations that have not started integrating PQC in their systems or even planning for it, we highly recommend starting their efforts now," the paper warns. "Those organizations and enterprises with sensitive data with time value exceeding five years should consider PQC immediately."

One of the co-authors of the paper is Jack Hidary, founder and CEO of Sandbox AQ, a software-as-a-service (SaaS) provider focused on bringing together quantum computing and artificial intelligence technology to address complex processing issues. The primary processing issue it is dedicated to is helping organizations understand the risk of quantum computing by identifying critical data assets that are encrypted and developing a strategy to protect them with the forthcoming PQC algorithms.

The first thing companies must do is undergo a discovery process to determine the value of all their data, particularly information that is encrypted. For example, a large pharmaceutical company could have IP for patented drugs that are worth billions of dollars per year in revenues and royalties. If that data were to end up in the wrong hands, it could render that IP worthless, Hidary warns.

"We realized that a white paper was necessary to give context to CISOs and to engineering teams and other leaders in the C-suite as to how this migration would occur," Hidary told Dark Reading. "And that's the motivation for this paper."

Hidary emphasizes that with SNDL, state-sponsored and independent attackers have already begun exfiltrating RSA encrypted data. "It's happening right now — they're storing that information, then they will decrypt in the future in a few years when they have additional computing power," he said. "That's the concern."

**PQC Attracts Powerful Friends**

Sandbox AQ may not be a well-known company today, having just come out of stealth mode. But it is a well-capitalized startup incubated by Google parent Alphabet, which spun out Sandbox AQ in March as a standalone company.

The company has a prominent advisory board consisting of former Google chairman and CEO Eric Schmidt, former U.S. Secretary of Defense Ashton Carter, former principal deputy director of National Intelligence Susan Gordon, and retired Admiral Mike Rogers, former Commander of the U.S. Cyber Command and a onetime director of the National Security Agency.

Before meeting with Hidary in January, Ernst & Young Americas cybersecurity lead David Burg said he knew PQC was an issue that his company would eventually have to address with its clients. But Burg acknowledges he was taken off guard over the need for EY to work on it with companies immediately.

"We left that meeting realizing that this is actually a problem set that our clients in the United States and around the world will need to deal with sooner than we thought," Burg says. The two companies formed a partnership to address the issue together.

**Protecting Health Information at Mount Sinai**

One of the clients EY is working with is the Mount Sinai Health System, which has 43,000 employees throughout its eight hospital campuses in the New York City area. Kristin Myers, who is Mount Sinai's CIO and dean of technology for its medical school, says cybersecurity is her No. 1 priority.

"In regard to quantum computing, the reality is that because of this innovation, it's going to be possible to decrypt data that is currently encrypted in the future," Myers says. "And as you can imagine for healthcare, an unauthorized disclosure of sensitive PHI \[personal health information\] would really impact patients, whether it happened now, five years from now, or beyond."

Myers says she signed up Mount Sinai with Sandbox AQ and will start conducting a review and inventory of all the encryption methods now in use. Sandbox AQ will then provide recommendations on how to move forward.

"We'll do a feasibility study of some of the products that we'll need to implement with them," she says. "This is going to be a multiyear journey with them, but just to be able to get started is going to be important for us."

Threat Actors Are Stealing Data Now to Decrypt When Quantum Computing Comes

With its latest mobile OS update, Google aims to simplify the adoption of Android’s protective features for users and developers alike.

For years, Android’s security and privacy teams have been wrestling the world’s most popular mobile operating system to make it more controllable and updatable while still being open source and easy to deploy. And while scams, malware, and rogue apps are still real threats, the debut of Android 13 at Google’s I/O developer’s conference on Wednesday feels less like triage mode and more like a logical iteration. As Charmaine D'Silva, Android’s director of product management puts it, “This is the release where we bring it all together.”

If anything, the big problem for Android security and privacy now is trying to get users, device makers, and developers to understand and be motivated to use a slew of new and recently released protective features. And after setting so many privacy and security initiatives in motion over the past few years, there's a huge amount for the Android team to maintain and try to get right at any given time.

“We will continue to go deeper, and that’s going to be a continued investment, but the challenge as you go deep is you end up fragmenting experiences, you end up actually confusing users unintentionally,” says Krish Vitaldevara, Android senior director of product management. “That’s a very hard problem to solve, and that’s what we’re going to solve with Android 13.”

Google Play Protect now scans about 125 billion apps per day on user devices to assess their behavior and attempt to identify security issues. And Google says that its Messages app now blocks 1.5 billion spam messages per month in an attempt to cut down on phishing and other scams that actually reach users. And after finally introducing end-to-end encryption in Messages last year for one-on-one texting with the long-awaited RCS messaging standard, Google says that later this year it will add end-to-end encryption in beta for group chats as well.

“We feel both excited and hopeful,” Jan Jedrzejowicz,  a Messages product manager tells WIRED. “Excited because providing out-of-box and encrypted-by-default group text messaging on Android is a huge upgrade for a large number of people all over the world. Hopeful because cross-platform messaging still uses SMS/MMS, and we really hope we can upgrade that to a more modern and encrypted protocol.”

Android 13 imposes more limitations and user controls for the permissions apps are granted and what data they can access when. For example, the operating system gives developers the option to easily incorporate Google’s “Photo picker” that lets users choose specific photos and videos to share with an app through the conduit of the picker, rather than granting the app access to their full photo library. Google has increasingly leaned on the system access that Android already has to provide specific data to apps, making it more like the bartender who’s mixing drinks than the cashier at the liquor store. Similarly, Android 13 now requires apps to request permission to access audio files, image files, and video files separately as part of an effort to limit access to different storage buckets.

Android already limited how much access apps had to the clipboard and notified users when an app grabbed something from it. But Android 13 adds another layer by automatically deleting whatever is in your clipboard after a short interval. This way, apps can’t find out old things that you copied, and—bonus—you’re less likely to inadvertently share your coworker’s list of reasons they hate your company with your boss. Android 13 also continues a process of reducing apps’ ability to require location sharing for things like enabling Wi-Fi. 

Android 13 requires new apps to ask permission before they can send you notifications. And the new release expands on a feature from Android 11 that automatically resets an app’s permissions once you haven’t used it for a long time. Since its debut, Google has extended the feature all the way back to devices running Android 6, and the operating system has now automatically reset more than 5 billion permissions, according to the company. This way, a game you don’t play anymore that had permission to access your microphone three years ago can’t still listen in. And Android 13 makes it easier for app developers to remove permissions proactively if they don’t want to retain access for longer than they absolutely need.

Making sure that Android devices around the world can get security updates has been a core hurdle for Google, since Android’s open source ethos allows any manufacturer to deploy its own version of the operating system. To improve the situation, the company has spent years investing in a framework called Google System Updates that breaks down the operating system into components and allows phone makers to directly send updates for the different modules through Google Play. There are now more than 30 of these components, and Android 13 adds ones for Bluetooth and ultra-wideband, the radio tech used at short range for things like radar.

Google is working to reduce common vulnerabilities that can show up in software by rewriting some crucial parts of the Android code base in more secure programming languages like Rust and creating defaults that nudge developers in a more secure direction with their own apps. The company has also worked to make its application programming interfaces more secure and has started offering a new service called Google Play SDK Index that provides some transparency into widely used software development kits, so developers can be more informed before they incorporate these third-party modules into their apps.

Similar to Apple’s iOS Privacy Labels, Android recently added a “Data Safety” field in Google Play to give users a sort of nutrition-fact label explaining how apps say they will handle your data. In practice, though, these types of disclosures aren’t always reliable, so Google is offering developers the option to have a third party independently validate their claims against an established mobile security standard. The process is still voluntary, though.

“We provide all these tools to developers to make their apps safer, but it’s important that they can actually prove that out and validate it through an independent third party, a set of labs testing against an established standard,” says Eugene Liderman, director of Android Security Strategy.

Android and Apple’s iOS have both been moving toward offering the ability to store government-issued identification. In Android 13, Google Wallet can now store such digital IDs and driver’s licenses, and Google says it’s working with both individual states in the United States and governments globally to add support this year.

With so much to focus on and refine, Android 13 attempts to take a sprawling situation and rein it in rather than letting it spin out of control. And Android's D'Silva says there's one release coming later this year that she's particularly looking forward to: a sort of safety center within Settings that will centralize privacy and security options in one location for users. An acknowledgment, perhaps, that it's all become too much for the average user to keep track of on their own.

Android 13 Tries to Make Privacy and Security a No-Brainer

Read access violation in the III_dequantize_sample function in mpglibDBL/layer3.c in mp3gain through 1.5.2-r2 allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact, a different vulnerability than CVE-2017-9872. CVE-2017-14409, and CVE-2018-10778.

Drive

Anmelden

Drive

Name

crash&analysis\_mp3gain.pdf

mp3gain\_poc

Keine Dateien in diesem Ordner.Melden Sie sich an, um diesem Ordner Dateien hinzuzufügen.

CVE-2021-34085: mp3gain_vuln – Google Drive

Red Hat Security Advisory 2022-1861-01 - Maven is a software project management and comprehension tool. Based on the concept of a project object model, Maven can manage a project's build, reporting and documentation from a central piece of information.

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

====================================================================                     
Red Hat Security Advisory

Synopsis:          Moderate: maven:3.5 security update  
Advisory ID:       RHSA-2022:1861-01  
Product:           Red Hat Enterprise Linux  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:1861  
Issue date:        2022-05-10  
CVE Names:         CVE-2020-13956  
====================================================================  
1. Summary:

An update for the maven:3.5 module is now available for Red Hat Enterprise  
Linux 8.

Red Hat Product Security has rated this update as having a security impact  
of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which  
gives a detailed severity rating, is available for each vulnerability from  
the CVE link(s) in the References section.

2. Relevant releases/architectures:

Red Hat Enterprise Linux AppStream (v. 8) - aarch64, noarch, ppc64le, s390x, x86_64

3. Description:

Maven is a software project management and comprehension tool. Based on the  
concept of a project object model (POM), Maven can manage a project's  
build, reporting and documentation from a central piece of information.

Security Fix(es):

* apache-httpclient: incorrect handling of malformed authority component in  
request URIs (CVE-2020-13956)

For more details about the security issue(s), including the impact, a CVSS  
score, acknowledgments, and other related information, refer to the CVE  
page(s) listed in the References section.

Additional Changes:

For detailed information on changes in this release, see the Red Hat  
Enterprise Linux 8.6 Release Notes linked from the References section.

4. Solution:

For details on how to apply this update, which includes the changes  
described in this advisory, refer to:

https://access.redhat.com/articles/11258

5. Bugs fixed (https://bugzilla.redhat.com/):

1886587 - CVE-2020-13956 apache-httpclient: incorrect handling of malformed authority component in request URIs

6. Package List:

Red Hat Enterprise Linux AppStream (v. 8):

Source:  
aopalliance-1.0-17.module+el8+2452+b359bfcd.src.rpm  
apache-commons-cli-1.4-4.module+el8+2452+b359bfcd.src.rpm  
apache-commons-codec-1.11-3.module+el8+2452+b359bfcd.src.rpm  
apache-commons-io-2.6-3.module+el8+2452+b359bfcd.src.rpm  
apache-commons-lang3-3.7-3.module+el8+2452+b359bfcd.src.rpm  
apache-commons-logging-1.2-13.module+el8+2452+b359bfcd.src.rpm  
atinject-1-28.20100611svn86.module+el8+2452+b359bfcd.src.rpm  
cdi-api-1.2-8.module+el8+2452+b359bfcd.src.rpm  
geronimo-annotation-1.0-23.module+el8+2452+b359bfcd.src.rpm  
glassfish-el-3.0.1-0.7.b08.module+el8+2452+b359bfcd.src.rpm  
google-guice-4.1-11.module+el8+2452+b359bfcd.src.rpm  
guava20-20.0-8.module+el8+2452+b359bfcd.src.rpm  
hawtjni-1.16-2.module+el8+2452+b359bfcd.src.rpm  
httpcomponents-client-4.5.5-5.module+el8.6.0+13298+7b5243c0.src.rpm  
httpcomponents-core-4.4.10-3.module+el8+2452+b359bfcd.src.rpm  
jansi-1.17.1-1.module+el8+2452+b359bfcd.src.rpm  
jansi-native-1.7-7.module+el8+2452+b359bfcd.src.rpm  
jboss-interceptors-1.2-api-1.0.0-8.module+el8+2452+b359bfcd.src.rpm  
jsoup-1.11.3-3.module+el8+2452+b359bfcd.src.rpm  
maven-3.5.4-5.module+el8+2452+b359bfcd.src.rpm  
maven-resolver-1.1.1-2.module+el8+2452+b359bfcd.src.rpm  
maven-shared-utils-3.2.1-0.1.module+el8+2452+b359bfcd.src.rpm  
maven-wagon-3.1.0-1.module+el8+2452+b359bfcd.src.rpm  
plexus-cipher-1.7-14.module+el8+2452+b359bfcd.src.rpm  
plexus-classworlds-2.5.2-9.module+el8+2452+b359bfcd.src.rpm  
plexus-containers-1.7.1-8.module+el8+2452+b359bfcd.src.rpm  
plexus-interpolation-1.22-9.module+el8+2452+b359bfcd.src.rpm  
plexus-sec-dispatcher-1.4-26.module+el8+2452+b359bfcd.src.rpm  
plexus-utils-3.1.0-3.module+el8+2452+b359bfcd.src.rpm  
sisu-0.3.3-6.module+el8+2452+b359bfcd.src.rpm  
slf4j-1.7.25-4.module+el8+2452+b359bfcd.src.rpm

aarch64:  
jansi-native-1.7-7.module+el8+2452+b359bfcd.aarch64.rpm

noarch:  
aopalliance-1.0-17.module+el8+2452+b359bfcd.noarch.rpm  
apache-commons-cli-1.4-4.module+el8+2452+b359bfcd.noarch.rpm  
apache-commons-codec-1.11-3.module+el8+2452+b359bfcd.noarch.rpm  
apache-commons-io-2.6-3.module+el8+2452+b359bfcd.noarch.rpm  
apache-commons-lang3-3.7-3.module+el8+2452+b359bfcd.noarch.rpm  
apache-commons-logging-1.2-13.module+el8+2452+b359bfcd.noarch.rpm  
atinject-1-28.20100611svn86.module+el8+2452+b359bfcd.noarch.rpm  
cdi-api-1.2-8.module+el8+2452+b359bfcd.noarch.rpm  
geronimo-annotation-1.0-23.module+el8+2452+b359bfcd.noarch.rpm  
glassfish-el-api-3.0.1-0.7.b08.module+el8+2452+b359bfcd.noarch.rpm  
google-guice-4.1-11.module+el8+2452+b359bfcd.noarch.rpm  
guava20-20.0-8.module+el8+2452+b359bfcd.noarch.rpm  
hawtjni-runtime-1.16-2.module+el8+2452+b359bfcd.noarch.rpm  
httpcomponents-client-4.5.5-5.module+el8.6.0+13298+7b5243c0.noarch.rpm  
httpcomponents-core-4.4.10-3.module+el8+2452+b359bfcd.noarch.rpm  
jansi-1.17.1-1.module+el8+2452+b359bfcd.noarch.rpm  
jboss-interceptors-1.2-api-1.0.0-8.module+el8+2452+b359bfcd.noarch.rpm  
jcl-over-slf4j-1.7.25-4.module+el8+2452+b359bfcd.noarch.rpm  
jsoup-1.11.3-3.module+el8+2452+b359bfcd.noarch.rpm  
maven-3.5.4-5.module+el8+2452+b359bfcd.noarch.rpm  
maven-lib-3.5.4-5.module+el8+2452+b359bfcd.noarch.rpm  
maven-resolver-api-1.1.1-2.module+el8+2452+b359bfcd.noarch.rpm  
maven-resolver-connector-basic-1.1.1-2.module+el8+2452+b359bfcd.noarch.rpm  
maven-resolver-impl-1.1.1-2.module+el8+2452+b359bfcd.noarch.rpm  
maven-resolver-spi-1.1.1-2.module+el8+2452+b359bfcd.noarch.rpm  
maven-resolver-transport-wagon-1.1.1-2.module+el8+2452+b359bfcd.noarch.rpm  
maven-resolver-util-1.1.1-2.module+el8+2452+b359bfcd.noarch.rpm  
maven-shared-utils-3.2.1-0.1.module+el8+2452+b359bfcd.noarch.rpm  
maven-wagon-file-3.1.0-1.module+el8+2452+b359bfcd.noarch.rpm  
maven-wagon-http-3.1.0-1.module+el8+2452+b359bfcd.noarch.rpm  
maven-wagon-http-shared-3.1.0-1.module+el8+2452+b359bfcd.noarch.rpm  
maven-wagon-provider-api-3.1.0-1.module+el8+2452+b359bfcd.noarch.rpm  
plexus-cipher-1.7-14.module+el8+2452+b359bfcd.noarch.rpm  
plexus-classworlds-2.5.2-9.module+el8+2452+b359bfcd.noarch.rpm  
plexus-containers-component-annotations-1.7.1-8.module+el8+2452+b359bfcd.noarch.rpm  
plexus-interpolation-1.22-9.module+el8+2452+b359bfcd.noarch.rpm  
plexus-sec-dispatcher-1.4-26.module+el8+2452+b359bfcd.noarch.rpm  
plexus-utils-3.1.0-3.module+el8+2452+b359bfcd.noarch.rpm  
sisu-inject-0.3.3-6.module+el8+2452+b359bfcd.noarch.rpm  
sisu-plexus-0.3.3-6.module+el8+2452+b359bfcd.noarch.rpm  
slf4j-1.7.25-4.module+el8+2452+b359bfcd.noarch.rpm

ppc64le:  
jansi-native-1.7-7.module+el8+2452+b359bfcd.ppc64le.rpm

s390x:  
jansi-native-1.7-7.module+el8+2452+b359bfcd.s390x.rpm

x86_64:  
jansi-native-1.7-7.module+el8+2452+b359bfcd.x86_64.rpm

These packages are GPG signed by Red Hat for security.  Our key and  
details on how to verify the signature are available from  
https://access.redhat.com/security/team/key/

7. References:

https://access.redhat.com/security/cve/CVE-2020-13956  
https://access.redhat.com/security/updates/classification/#moderate  
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.6_release_notes/

8. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2022 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBYnqSLNzjgjWX9erEAQjzMA//Uavi6D7MDYrDnmGgbzQb9t0G04pdW1SI  
TDBubj2p3eT4fcUiLD1/gBlhrw7sJyn+3qaVU9yx6pr7rzR44q5KCvPestiHDQ6u  
/KwgZudXrySYli65OcidV+cdTCk7cbWY3FILE8vHRIP7mqouFY/dVcmpspGKj0ti  
Pz8XlMBc9UxjbALpxMYfv0Upo6EJbktdRduwzailGzM7tL36yuxV4X3hOu1CoxZg  
RJbfluZRXJGYuuaHiIUOcC6nVsYCAzDQBbMkrb5Pexp7b0sZRBW6CnAO9/aLvxel  
M9GZt2HQXlQGDBbfLrwiDP46vSRSqMdNkt7ppeDVEUJmvcgBxOKlgAC91WGLrYKV  
zTYNCjY2MqvZCUHmobPOPDjzMQ5+wkCibdtKbra2RVHyF/41C+QCxmfiArBWqMkl  
mAC/b8PrIeHS8tM9K55vSAcFVyY6BRA+x0YZZ2NLJSTMvZpUViIe/57Q2h/lsmZC  
YjVRzACxgvvLIQbDA1JQw7AfLVUGPQsGA5YDdwHk4LLFma8uXqHsA216qlZAX0C0  
54b1hmPhFwzRNvR7Rw2ugI6b32TTtFjm/SwmSVEQfU9tp2V9lijIa8dobHLyvzbX  
Tm99BZ3r51dzDE41J8pbOhdeT4OhYr6N+DRuOkiU+lgQ1BDz3wlqYjVxBZoyMUWP  
aWxK8LwsKrY=ayNO  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Tag

#google