Affected: excon

Excon is usable, fast, simple HTTP 1.1 for Ruby. Prior to 1.5.0, Excon's RedirectFollower middleware failed to strip additional sensitive headers when following redirects and did not provide a custom list of headers to strip. This could cause inadvertent leakage of sensitive data when the initial request includes header information that is not intended for the new target. This issue is fixed in version 1.5.0.

Affected: RubyGems: concurrent-ruby

### Summary `Concurrent::ReadWriteLock#release_write_lock` does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running.

`Concurrent::ReadWriteLock#release_read_lock` also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from `0` to `-1`, after which normal read acquisition raises `Concurrent::ResourceLimitError`.

This is a synchronization correctness issue in the public `Concurrent::ReadWriteLock` API. It should not be framed as an authorization bypass; the lock is an in-process concurrency primitive, not an access-control boundary.

### Version Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab

### Details

`release_write_lock` checks only whether the global counter indicates that a writer is running. It does not track or verify ownership:

```ruby def release_write_lock return true unless running_writer? c = @Counter.update { |counter| counter - RUNNING_WRITER } @ReadLock.broadcast @WriteLock.signal if waiting_writers(c) > 0 true end ```

Because ownership is not checked, a different thread can clear the `RUNNING_WRITER` bit while the original writer is still inside its critical section. Another writer can then acquire the write lock and run concurrently with the first…