Password beginning with backslash returned as double-backslash (escaping issue?)

[defron]

Describe the issue It looks like backslashes in the password are being escaped with a double-backslash, at least if they appear at the beginning of the string.

To Reproduce Steps to reproduce the behavior:

1. Password in CyberArk starts with a single backslash
2. get data using $securePass= (Get-PASAccount -search $userName | Get-PASAccountPassword).ToSecureString()
3. Create credential object using that password
4. $cred.GetNetworkCredential().Password | Set-Clipboard to get password into clipboard
5. The password starts with double-backslash instead of the expected single backslash

Expected behavior Password returned should not be escaped. Using

$securePass = (Get-PASAccount -search $userName | Get-PASAccountPassword -UseClassicAPI).ToSecureString()

correctly returns the password with just a single backslash

Screenshots & Console Output If applicable, add screenshots to help explain your problem.

Console Output Code Block:

$securePass = (Get-PASAccount -search $userName | Get-PASAccountPassword).ToSecureString()
$cred = New-Object System.Management.Automation.PSCredential('testuser', $securePass)
cred.GetNetworkCredential().Password | Set-Clipboard

Your Environment Include relevant details about your environment

• PowerShell Version: Both 5.1 and 6.2.3
• psPAS Version: 3.2.37
• CyberArk Version: 10.5.0.48

Additional context Currently using a workaround -UseClassicAPI just don't know if the v9 APIs will be discontinued at some point by CyberArk

[pspete]

Thanks for the report @defron - I'll see if anything can be done

[defron]

Thanks!

This has been a really helpful project for my team after we started using CyberArk when sudoing and stuff.

Like I said, I was able to implement a work-around in the meantime so if it's not possible to fix it based on the way Cyberark returns data, just so long as this is documented for others to know to use the Legacy API if they run into this issue I think that's good enough.

[pspete]

Thanks for reporting this @defron - a really helpful issue for the module & it's users.

Fix implemented, and now present in version 3.3.88 on the master branch & published to the PowerShell Gallery.