Apache Log4j Security Vulnerabilities

A high severity vulnerability, (CVE- 2021-44228), impacting multiple versions of Apache Log4j utility, was disclosed publicly on December 9, 2021. The vulnerability impacts Apache Log4j 2 versions- 2.0 to 2.14.1. Find the details of this vulnerability documented here: https://logging.apache.org/log4j/2.x/security.html.

We have patched all our services as well as applied mitigation measures for the affected third party components. We have found no evidence of any successful exploitation. We are continuing to analyze the issue and will provide updates in this space, if there is.  Rest assured that our customers are not impacted by the vulnerability. For any additional details or assistance, you can reach out to us at: . We’d be happy to help.

Scale_with_Ease

No Demand is Too High

Helpshift utilizes an elastic infrastructure to automatically increase capacity based on demand. This allows us to support one billion devices and 80 million conversations per year. Scaling to thousands of agents isn’t an issue because no extensive training is necessary and onboarding takes just minutes.

Security_icon

As Secure as it Gets

Helpshift follows the most stringent security practices. We are compliant with GDPR, SOC2, HIPAA, COPPA, ISO27001, ISO27017, and ISO27018. Our services are hosted on Amazon Web Services (compliant with PCI DSS, SOC 1/2/3, ITAR, EU-US, and NIST). Data in transit is secured by TLS encryption. In addition, Helpshift employs third-party experts to conduct regular vulnerability testing.

software_trust

Software You Can Trust

We monitor our production services 24-7. We build resilience into our stateless, service-oriented architecture to enable fault isolation, loose coupling, and simpler testing. We cluster service instances so traffic goes unaffected. Load balancing also ensures that capacity can be added effortlessly when required, without affecting currently served production traffic.

email-v-messaging

Responsible Disclosure of Security/Privacy Vulnerability

Security is always at the top of our minds. We want to honor and value the security researcher community to aid us in maintaining our security posture. As part of this commitment, we want to set out some do’s and don’ts for responsible disclosure of vulnerabilities.

Please contact if you find any potential vulnerability in a *.helpshift domain. which meets the below criteria.

  • You can expect an acknowledgment from our team within 8 hours, or within 48 hours if you contact us on a weekend or holiday.
  • Helpshift defines the severity of a reported issue based on its impact and ease of exploitation.
  • It may take us 3 days or more to validate a reported vulnerability.
  • When conducting testing, you must not violate our privacy policy, modify/delete user data, conduct brute forcing/ rate limiting attacks or impact user experience.
  • Please treat information about any potential vulnerability that you may report as highly confidential. You should never disclose this to the public without our permission

What we expect in the report

  • Brief explanation that should detail the threat vector
  • Impact of the vulnerability. Does it affect a domain, a privilege, platform components, user privacy etc.  Please feel free to devise it the way you deem fit and per your understanding of the impact.
  • Proof Of Concept (steps to reproduce).  A visual POC would be very nice, using screen recording.
  • Your handle or name/alter ego for due recognition. You will be featured on our security page.
  • You will also duly be compensated for vulnerabilities that we construe as very high impact. (No, not in cryptocurrency!!)

Bugs we would like to see                                                           

  • Injections (XSS/CSV/HTML)
  • Request Forgery (SSRF and CSRF)
  • Server misconfigurations (public S3 etc.)
  • Broken Authorisation
  • Vulnerabilities found in third party components that we use

Bugs that will be considered as false positives/invalid. Please refraining from reporting:

  • Rate limiting, brute force/DDOS attack
  • Automated scans
  • Open redirections
  • Vulnerabilities that require physical access to be realised.
  • Phishing / Spamming (including issues related to SPF/DKIM/DMARC)
  • Metadata (EXIF, geolocation etc.) not masked on content such as images.
  • Self-XSS
  • Any bug without a proof of concept and explanation

If you have a bug that satisfies the above criteria, reach out to .

block background image